Mail Archives: cygwin-developers/1998/06/12/02:13:50
In article <m0ykAHT-00118cC DOT cygnus DOT cygwin32 DOT developers AT malasada DOT lava DOT net>,
Tim Newsham <newsham AT lava DOT net> wrote:
> Got a question. The do_exit() function (in dcrt0.cc) closes
>all the open files and then does sigproc_terminate to stop signal
>processing. Is there any reason the files should be closed first?
If the order is reversed then if there is a problem closing handles
that would have generated a signal, you'll never see the signal.
>During some high-load processing with lots of processes we occasionally
>see hung processes and once in a while a Dr Watson. I attached to
>one of the hung process at one point and got a stack trace and noticed:
>
> call handler
> .... (2 0x77f6xxxx addresses) ...
> _close
> close_all_files
> do_exit
> _exit
>
>This process was unkillable in cygwin. I'm not sure what was going
>on here. Would it help to disable signals earlier in the _exit sequence?
A process could be unkillable if it is blocked in some kind of I/O when
cygwin tries to call a signal handler.
>We've also seen two other anomolies recently that we haven't seen
>more than once:
>
> - commit_and_ic: Virtual Alloc Failed (is this a standard
> "out of memory" type of error?)
Don't know what this is.
> - call_handler: ouldn't[sic] get context of main thread. err 6
> (this was printed every time we tried to kill the process)
Well, the misspelling is fixed, but other that that, I don't know what
could have caused this. It sounds like the main thread died in that
process but other threads were still executing.
--
cgf AT cygnus DOT com "Everything has a boolean value, if you stand
http://www.cygnus.com/ far enough away from it." -- Galena Alyson Canada
- Raw text -