1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre

[Kiyo Kelvin Lee]

Now it seems the crashes are relating to another problem reported earlier:
1.5.20: Occasionally infinite loop happens in do_exit() (dcrt0.cc) (see 
attached original text below)

I managed to make sure the infinite loop had not happened (more about 
that later) and then tested to run configure for squid-2.6 multiple 
times (ran for 2 hours) and was unable to reproduce a single crash.

So I am guessing the infinite loop and hence explicitly killing the 
offending process would leave cygwin in some funny state and lead to 
those crashes.

The infinite loop problem happened fairly often whenever I started X 
Windows. And I basically did all the tests inside xterm, i.e. always 
after an infinite loop had happened. I started to notice the potential 
relationship when I had successfully run configure for squid-2.6 without 
any crash inside just bash with no X Windows running at the time.

And I notice the infinite loop problem seems to be relating epist, a 
utility comes with and for openbox 2.3.1 which I built myself and use as 
the windows manager. (Note that the official cygwin openbox is still of 
version 0.99) Once I have removed epist from starting in xinitrc, the 
infinite loop problem no longer happens and that allows me to do the 
test above.

As to why I wondered that epist is part of the problem is that there is 
a strange characteristic about it. That is the process is not listed 
with ps or procps or even ps -W (as a Windows process) but indeed it is 
running and functional. (Unbelievable?) It is still shown in Task 
Manager of course but just like invisible inside cygwin. And it won't be 
killed automatically upon terminating X Windows. I need to kill it 
explicitly after terminated X Windows.

If this is not complicated enough, I have to mention openbox 2.3.1 
cannot be built by default on cygwin as it requires gcc-2.95. So I have 
to fix it to support gcc-3.4.4, the current official cygwin gcc, and 
tweak Makefiles after configure (to link to Xft, fontconfig, iconv) to 
build. If you would like to test all these (I'd be very grateful if you 
do so), you may like to take my attached patch for openbox 2.3.1.

Regards,
Kiyo

### Problem reported earlier ###
1.5.20: Occasionally infinite loop happens in do_exit() (dcrt0.cc)
==================================================================
Using 1.5.20-1 on Windows XP, occasionally a process would become 
consuming all CPU cycles (90+%) upon termination.
Tested snapshot 20060707 and the problem persists.
I debugged into the process using msdev and found the attached stack trace.
The infinite loop is inside ntdll.
0x61004b4c is the last address in cygwin1 which has never been get back to.
BTW, the address corresponding to line 1113 of dcrt0.cc (snapshot 
20060707) function do_exit() at the line:
     cygwin_shared->tty.terminate();

So look very much like a problem I reported before for 1.5.19-4.
But that one was constantly reproducible with running gvim in diff mode.
And that problem has been gone with 1.5.20-1.

Now, the infinite loop problem happens more unpredictably and just 
occasionally.
------------------------------------------------------------------

Christopher Faylor wrote:
> On Wed, Jul 19, 2006 at 05:30:05PM +1000, Kiyo Kelvin Lee wrote:
>> Actually, I have 2 systems (one XP [AMD Athlon 64 3500] and one Win2K 
>> [Celeron 900]) both have the same problem and attached are the cygcheck 
>> output.
>>
>> My sh.exe is bash.exe.
>>
>> The crashes happen just sparsely and not upon all processes termination. 
>> When I ran, say, configure for openbox-2, I always got at least a few 
>> crashes but the configure procedure should have already ran hundreds of 
>> processes. Note the crashes did not seem to affect the configure procedure 
>> and configure finished just normally.
>>
>> I tried to debug bash and get the stack trace with no success.
>> The crashing dialog is like attached to a ghost process. Click on CANCEL  
>> does not start msdev.exe as the debugger.
> 
> Running msdev wouldn't be very interesting anyway.
> 
> Possibly setting CYGWIN=error_start=c:/cygwin/bin/gdb.exe might cause
> gdb to pop up, however.
> 
>> Also tried to attach to a bash using gdb before running configure, the 
>> crashes still happen but gdb just couldn't catch anything, the bash just 
>> kept running (inside gdb).
> 
> I'm not sure what this means.  If bash kept running then that would
> indicate that it isn't the bash which is crashing.  Possibly a forked
> 
> cgf
> copy is crashing.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openbox-2.3.1-p1-patch.diff
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060722/1c046f65/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/