From: cgf AT cygnus DOT com (Christopher G. Faylor) Subject: Re: do_exit and signals? 12 Jun 1998 02:13:50 GMT Message-ID: <6lq2su$fsj$1@cronkite.cygnus.com> References: X-Newsreader: trn 4.0-test63 (15 March 1998) In article , Tim Newsham 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