Re: Stability issues with current Debian

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hi Hans,

On Sat, 2004-05-15 at 17:53, Hans Ronne wrote:
> >I can confirm that xconq freezes randomly on my debian unstable
> >system as well. This occurs in standard and intro games.  The
> >freeze does not generate a Xconq.Warnings file. Below is the gdb
> >output you requested from Martin, but it does not look too
> >helpful.
> >
> >#0  0x402a0115 in pthread_cond_wait@@GLIBC_2.3.2 ()
> >   from /lib/tls/libpthread.so.0
> >#1  0x401a2b32 in Tcl_ConditionWait () from /usr/lib/libtcl8.4.so.0
> >#2  0x401a36f5 in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0
> >#3  0x4017fc8c in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0
> >#4  0x0804fb45 in ui_mainloop () at tkmain.c:1977
> >#5  0x0804ae12 in main (argc=1075555836, argv=0xbffffbf4) at tkunix.c:126

This is the pretty much the same stack trace that Martin sent me just a
little while ago. I believe that this is an issue due to the Tcl lib
likely being built multithreaded on the Debian GNU/Linux systems. Our
first indicator that something was amiss probably came some months ago
when we had that chat with David Ronis (?) after he posted to the list.

I just made a little patch to tell the Tcl event handler to please not
do any blocking waits, because multithreaded Tcl may be spawning another
thread to wait, and then that thread is sitting around indefinitely
while other event handling requests pile up.... Just speculation; would
have to look at the Tcl sources to verify this.

If this patch doesn't work, I have another idea which involves calling 
'Tcl_SetMaxBlockTime' with a 0 s, 0 us block time, after we instantiate
the interpreter.

Eric