[any thoughts on where to begin helping someone with this problem?]
DKF: Oh dear. It is the intention of the Tcl Core Team that Tcl should be uncrashable. This is not always possible to achieve though. But here are some steps to follow when in this situation.
1: Don't Panic
There's never any need to panic about this sort of thing. It just makes life harder for no gain.
2: See if the Crash is Repeatable
Unrepeatable crashes are virtually impossible to hunt down, unless you're lucky enough to have a core dump and the binary file with symbols attached.
3: See if Tcl is using any Extensions/Binary Packages
It is very easy to destablilise Tcl by loading broken binary code as an extension or package. If there is code outside of Tcl itself (and Tk too) then there's a fairly high chance that the problem isn't Tcl, and should be reported to a different maintainer.
4: Get a Short Script that Causes the Crash Every Time
Getting a script that causes your crash every time is tantamount to demonstrating what the problem actually is. It also allows someone with a debugging build to track down exactly what is failing.
5: Report the Problem on SourceForge
Go to http://tcl.sourceforge.net/ and click on the appropriate link there to report a bug. If the bug appears to require Tk, report it as a Tk bug, and otherwise report it as a Tcl bug. Please provide plenty of information. Definitely include the patchlevel of Tcl that has the problem, as reported by [info patchlevel], and definitely include the script that reproduces the bug (taking care if you're using the file attach mechanism - SF requires that you check the box, give the filename and give a description.) And it helps if you've got yourself an SF account set up first; like that you will get automatically notified of progress towards resolution of the bug. Knowing what kind of system you are using is also quite helpful at times.
JMN I've had more than one or two crashes of tclsh/wish, but unfortunately it's very rare that I can work out how to produce a 'Short Script that Causes the Crash Every Time'. I tend to use a multithreaded version and a lot of packages - and usually the app involved is something of a large messy beast. This means that if it's a crash that occurs on exit, or happens rarely enough in an unimportant part of an App - I'll ignore it, upgrade to later CVSed versions of TCL as they come - and cross my fingers. I feel guilty that this isn't helpful as far as progressing the stability of TCL.
I've noticed however that some other programs.. MS Internet Explorer and Mozilla for example, have some sort of monitoring process that detects a crash and offers to automatically collate some relevant information and post it back for use by developers. Could something like this be developed as a package for TCL? What would be involved?
This crashes Tcl 8.3.5, threaded on Linux and Solaris:
proc crash { } {
if { [ catch {
if { [ info exists X ] } {
if { 1 } {
# the next line is the killer
set X "oops
}
}
} err ] } {
}
}RS also saw it crash on unthreaded tclsh 8.4.1 on Linux, and 8.4.2 on Windows 2000 (AS build).
JH That bug is fixed already in 8.4.4. It occurs when syntax errors are contained in a catch.
DGP Tcl Bug 705406, for your reference. [L1 ]
willdye If you get the message "GetCmdLocEncodingSize: bad code length" in a crash, and the Tcl/Tk version is prior to 8.4.4, it might be due to Tcl Bug 705406. If upgrading to a newer version of Tcl/Tk is problematic, then it might help to look for syntax errors inside of a "catch" statement. I'm quoting the message here so that others can find it in a wiki search, but I can't guarantee that bug 705406 will always generate that particular message, and of course getting that message might not be the result of that particular bug.
The purpose of this page is to collect helpful hints, pointers, etc. for someone attempting to determine what might have caused their application to crash.
RS: I cannot contribute much to this topic - my Tcl apps crash less often than does my Window sessions. ;-)
too deep recursion (?), other?
Can we be more precise about just what crash is supposed to mean?
An uncaught error in script evaluation can cause the shell evaluating that script to exit, usually with a display of the error message and $::errorInfo, the Tcl stack trace. Exceeding Tcl's limits on Tcl_Eval() recursion is in this category.
A call to Tcl_Panic() can abort a running program that includes Tcl. An error message should be displayed somehow before the abort(), and the abort() may drop you into a debugger. Running out of memory during a call to Tcl_Alloc() should lead to a Tcl_Panic().
Finally, the most mysterious of all are catastrophic failures with no more message than Segmentation fault or Bus error. Something like that indicates a serious bug (probably involving pointer management) in either Tcl or one of the C-coded packages being used by the program.
These are very different kinds of problems. Which one are we talking about on this page?
I think that, from a user perspective, these are likely to all appear the same - so either coverage of each here, or on independent pages, would make sense.
What _I_ had in mind initially were those process terminations which provided little in terms of assistance for resolution (the Segmentation Faults or aborts)...
Some of the most frustrating "debugging" sessions have arise when an application "works" in one circumstance, and crashes in another that's apparently identical. Sometimes the difference has to do with covert "magic names".
Arts and crafts of Tcl-Tk programming