Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: From: "Bryant, Nathan" To: "'bucweat_20657'" , cygwin AT cygwin DOT com Subject: RE: pthread app hangs after Ctrl+C Date: Thu, 6 Sep 2001 23:02:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi, Charlie. Both my application and DLL are built with Cygwin, using GNU libtool; so the DLL is also linked to Cygwin. As a little bit of background, this was necessary in order to port a network service written for Unix. The service used dlopen()able modules that link against the main executable, which was built with --export-dynamic. DLL's can't link to an EXE on Windows, so most of the application had to be moved into a DLL so that the dlopen modules could link. So unless i reshuffle code a bit further, there are some signal handlers that are being built into the DLL, because I've moved everything except main() into the DLL. It certainly sounds like the same or similar problem; when I get a moment of free time, I'll go over the sources you mentioned and try to find some common threads. This app spends a lot of time select()ing on a set of TCP sockets, and blocking on thread mutexes while waiting for another thread to get done select()ing. It also uses a pipe for communication between threads; one thread can force the select()ing thread to wake up early by sending a byte down this pipe. Occasionally it will write a message to the console, but normally only when there's some sort of activity. There wasn't much activity at the times I hit Ctrl-C to shut it down. So at the time of the ^C there were probably 4-5 threads in pthread_mutex_lock() and one in select(). -----Original Message----- From: bucweat_20657 [mailto:bucweat_20657 AT yahoo DOT com] Sent: Thursday, September 06, 2001 10:05 PM To: Bryant, Nathan; cygwin AT cygwin DOT com Subject: 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" control-c issue when running VC++ console programs in bash.exe 35104 by: "bucweat_20657" 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 ) 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 )? 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 AT allegientsystems DOT com] Sent: Wednesday, September 05, 2001 8:28 PM To: 'cygwin AT cygwin DOT 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. <> _________________________________________________________ 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/