Re: Newest code crashes Tcl/Tk

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

Hi Brian,

On Thu, 24 Jun 2004, Brian Dunn wrote:

> I can get it to freeze after I quit and am simply clicking 
>around the map before final game shutdown.

OK, thanks for the clarification.

> > On a system with protected memory and whatnot, this is fairly hard to
> > imagine, unless there are other factors involved such as a flaky video
> > card or some sort of faulty in-kernel video support. Furthermore, this
> > does not seem to happen on my development system.
> 
> All other operations seem ok.  No system locks other than Xconq.

OK.
 
> Debian Stable/Woody, nothing added, kernel 2.4.18-bf2.4, tcl/tk 8.3.

OK.

> > does it have NPTL support, does it have DRM support?
> 
> neither 'nptl' nor 'drm' shows up with apt-cache search nor with man -k

I would not expect them to show up with "man -k". I don't know 
about apt-cache, since it has been a long while since I have used 
Debian.

For DRM, at least, you will probably have to "grep DRM" on your  
kernel's config file. In the case of NPTL, it may simply be a 
matter of seeing whether it is in your libc's full name. However, 
I doubt that NPTL is the issue or that you are using it on your 
system with the older 2.4 kernel.

I am not sure that DRM or other kernel special video support is an 
issue either.

>   And some other
> > details: what version of Tcl and is it compiled for multithreading
> 
> Unknown about multithreading.  Doesn't show up in apt-cache search

You can get that from your 'tclConfig.sh' file, which, on Debian, 
is probably located in '/usr/lib/tcl8.3'.

> , and
> > what version of XFree86
> 
> 4.01
> 
> > and which of its extension modules are loaded?
> 
> Quite a list is shown.  Want the whole list?  Anything in particular to look for?

Nothing in particular at this point. If you want to give the whole 
list (via private email), you can. If you just do an "xset q", it 
should mention which ones are actually loaded by the presently 
running X server.

To be honest, my line of diagnosis was probably a bit off track 
when I mentioned NPTL or DRM. In the case of NPTL, I was concerned 
that maybe multithreaded Tcl was having a bad interaction with it, 
and destabilizing the system somehow. However, this seems 
_extremely_ unlikely.
The other thought was that some sort of in-kernel video support 
was somehow getting abused by Xconq/Tk/X and thereby causing 
problems. However, this also seems unlikely.

I think the best place to be looking is how Xconq/Tk might be 
abusing the X server. One thing that I do wonder about is how hard 
your system was really locked?

If the just X server is partially frozen, then you might be able 
to do a CTRL-ALT-BACKSPACE to kill off the server or a 
CTRL-ALT-F1 to get to tty1 (function keys combinations using F2 
through F6 are probably also available, and should drop you to 
tty's 2 through 6, respectively). If the server is busy choking on 
something, then you might need to wait a minute or two for it to 
honor your request.

If the X server is totally frozen, then, if you have another 
machine handy, you might be able to remote login (say with ssh) 
and "kill -9" the X server out of its miserable existence.

Then again, the X server might be okay, and it might be something 
evil happening with your window manager/desktop environment. In 
that case, maybe you could play with running Xconq under a 
different Window manager (perhaps a simpler one such as FVWM2, or 
even TWM).

In any case, I am more inclined to suspect that the "hard" lock 
only extends as far as the X stuff, and that the OS kernel is 
probably working just fine.

My suggestion would be that we try to verify that either the X 
server or else the window manager is getting hurt, and then start 
looking at various scenarios from that point. Considering that the 
Tcl/Tk interface on Linux/Unix systems already produces a number 
of "BadDrawable" and "BadWindow" errors (which are shown on 
whatever terminal window, 'xconq' is launched from), there is 
already circumstantial evidence to suggest Tkconq is not a 
well-behaved X11 app.

Eric