This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: pthread app hangs after Ctrl+C


Hi Nathan,

I've run into some similar issues recently and so would like to add my $0.02
to show that more than one person has encountered it... check out the
following from this list regarding issues with signals (35104 contains some
good gouge from Troy Noble on this and some source code to try):

signals and VC++
	34947 by: "bucweat_20657" <bucweat_20657@yahoo.com>

control-c issue when running VC++ console programs in bash.exe
	35104 by: "bucweat_20657" <bucweat_20657@yahoo.com>

I also sent the emails follow this to the person who developed a cygwin port
of wpcap.dll, which sounds very similar to your description. Question: where
did your .dll/.lib come from? Did you do a mapping of the .lib as described
by the FAQ (a la <http://cygwin.com/faq/faq_toc.html#TOC91>) to a lib.a? Do
you have a simple example program that illustrates the problem?

*********** first email ( a little light reading :-) ****************

I've been playing around with the cygwin version of wpcap. I've come across
some interesting things that I was hoping to run by you to see if you've had
similar issues. So, if you've got a moment or too, please read on...

I currently have a command line program that I've written using MSVC++ that
uses winpcap (it's similar to ngrep actually). However, I'd like to be able
to run in bash shell. It turns out that signals from MSVC++ compiled
programs don't work well when run in bash (long story...minor details
coming). So, I tried compiling using g++ now that it is supported, thanks to
yourself :). I ran into some initial problems, so I simplified things by
working with a copy of the pcap_filter example that comes with Wpdpack
(version 2.2). I've implement a simple signal handler that sets a flag, and
replaced pcap_loop() with pcap_dispatch() so I can handle some event loop
stuff and allow for cleanup at the end via a clean_exit() function. Now when
I run the app and press control-c, the signal is trapped, calling a handler
which sets a flag. This exits a while( exitFlag == false) loop, where a
clean_exit() function is called, and then the program exits (firing off
destructors as required). This works fine. But keep reading...

In order to get signals to work correctly, I had to remove the -mno-cygwin
option. Why, you wonder? When you use this you end up with a DOS shell
program, which runs inside a stealth bash (compare windows NT/2000 task
manager to results of ps). When you control-c, the stealth bash shell and
its child app are killed immediately...no chance for destructors and
clean_exit() type functions to run. When compiled without -mno-cygwin the
program is compiled as a cygwin app and signals are handled correctly.

So, if you've got this far, the issue I'm seeing is that when the control-c
is issued, it takes awhile for the signal to get to the program. If you
comment out the pcap_dispatch() and replace with a usleep() to simulate the
timeout, the signal is handled immediately. Any ideas on how the cygwin
version of the library handles signals? Did you do a mapping of the .lib as
described by the FAQ (a la <http://cygwin.com/faq/faq_toc.html#TOC91>)? Any
help or insights you could provide would be greatly appreciated.

************* followup ********************

A possible major update...I've noticed that when I run the example program I
sent to you and control-c, the program seems to exit relatively quickly if
the program is writing periods (".") to the screen AND when you select
another window (i.e. as soon as the bash window looses focus). However, if
you comment out "theDot()" function (in while loop at end of main) and
recompile, the program "hangs" with the CPU at 100% like before (a la
endless loop) and clicking another window has no affect, and it takes much
longer to exit if at all (ps -KILL still works).

So it would appear that writing to the console and changing window focus has
some affect on how control is passed around. I've tried running in the
debugger and it locks up. If you get a chance to try the program I'd be
interested to see if you get similar results.

BTW this program is available upon request, but you'll need wpcap to compile
and run it.

***************************************
VR, Charlie

-----Original Message-----
From: Bryant, Nathan [mailto:nbryant@allegientsystems.com]
Sent: Wednesday, September 05, 2001 8:28 PM
To: 'cygwin@cygwin.com'
Subject: pthread app hangs after Ctrl+C


Hi,

I have an application that hangs after Ctrl+C is pressed. I'm currently
running Cygwin DLL 1.3.2. Windows 2000's Task Manager shows the CPU at 100%
after ctrl+c, as long as the command window is in the foreground -- it idles
again if I Alt+tab somewhere else.

there are a couple oddball things that it's doing:

 - the signal handler for SIGINT is a static function in a DLL. (the signal
handler just immediately returns, at the moment, but the behavior is the
same if it sets a volatile int to 1, signalling the main loop to quit...)
 - the app uses pthreads.

it dies properly if i remove the signal handler entirely, and also exits
normally if i just do 'kill -INT' from another bash window, even if the
signal handler is installed; the problem only seems to appear with Ctrl+C.

If there is need, I could try to come up with a minimal test case, but maybe
this is already known and fixed in cygwin-current?


cygcheck output is attached.

 <<cygcheck.out>>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]