delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/06/13/22:40:43

From: sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Subject: RE: SIGKILL and block_sig_dispatch
13 Jun 1998 22:40:43 -0700 :
Message-ID: <01BD9776.F2037590.cygnus.cygwin32.developers@sos>
To: "cygwin32-developers AT cygnus DOT com" <cygwin32-developers AT cygnus DOT com>,
"'Tim Newsham'" <newsham AT lava DOT net>

Tim Newsham wrote:
>      I have put block_sig_dispatch()/allow_sig_dispatch() around a
> few calls in net.cc to protect them from signals (when signals come
> in during certain calls, my socket handles seem to get messed up).
> Now I'm seeing some signal weirdness.  It seems to properly handle
> receiving most signals; it just defers the signal until the allow
> call gets called.  But, when I send a SIGKILL, the program dumps
> core when the allow_sig_dispatch() call is finally made.  I can

> (c:\home\test\tests\a.exe 1069) <1> __cygwin32_exception_handler: In 
cygwin32_except_handler exc C0000005 at 74FF21FA sp 244F760
> (c:\home\test\tests\a.exe 1069) <0> __cygwin32_exception_handler: In 
cygwin32_except_handler sig = 11 at 74FF21FA

I don't know if there are some relations, but the trap address is well 
known for me :-)
When cygwin application while in a blocking winsock call receives any 
signal whose disposition is to terminate a process, the application traps 
in a system dll when calling WSACleanup() (exception.cc, routine 
sig_handle, label exit_sig). Try to remove this call and see what will 
happen. But it will be impossible to kill cygwin application untill a 
blocking winsock call terminates:-(

What are the reasons to call do_exit() in a context of main thread? Why not 
suspend main thread and to call do_exit in the context of signal processing 
thread (with the call to WSACleanup() removed)?

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019