Mail Archives: cygwin-developers/1998/06/13/22:40:43
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 -