How to crash Tk 8.4 under KDE 3.0
Csaba Nemethi
METHOD #1: Install my Tablelist package, execute the demo script
"styles.tcl", select an arbitrary item, and then click on the "Close"
button. This terminates the program (which is OK), but also raises
the message "Segmentation fault". Note that Tablelist is written in
pure Tcl code! (Andres Garcia sent me another example two months
ago, but at that time I still had KDE 2, which caused no problems;
now that I run KDE 3.0, I can confirm that wish8.4 crashes with that
script, too.)
METHOD #2: Install Bryan Oakley's mclistbox, evaluate the script
"example.tcl", and close the window by clicking on the "x" in its
top-right corner. You will see the same "Segmentation fault"
message. This is another extension written in pure Tcl code that
crashes Tk 8.4 under KDE 3.0!
METHOD #3: Consider the following simple script:
set win .f
label $win -text "I am the selection owner.\nClick on <Close>."
selection own $win
selection handle $win [list fetchSelection $win]
button .b -text "Close" -command exit
pack $win .b -padx 10 -pady 5
proc fetchSelection {win offset maxChars} {
return ""
}
Running the script with wish8.4 and clicking on the "Close" button
raises the message "Segmentation fault". This script also shows one
point that Tablelist and mclistbox have in common: both make use of
the "selection own" and "selection handle" commands to implement the
"-exportselection" option. When selecting an item in a tablelist or
mclistbox widget having "-exportselection" set to true (the default),
the "selection own" command is invoked, making the widget the owner
of the selection. KDE then attempts to retrieve the selection, and
wish answers by invoking the command specified by "selection handle".
(Note that mclistbox invokes "selection own" also within the
"selection anchor" listbox operation; this is IMHO not quite OK, but
at the same time it explains the fact that the crash in Method #2
above occurs even if no item was selected.)
The abnormal termination seems to be caused by a bug in the C-code
related to the "selection handle" command. After experiencing the
problem using the ActiveState binary distribution, I compiled Tcl and
Tk 8.4.1 with the TCL_MEM_DEBUG flag and ran the script again. The
result was a premature termination of the program with the message
unable to alloc 1633771903d bytes,
/home/csaba/tcltk/tk8.4.1/generic/tkSelect.c line 1382
(BTW: The "d" appended to the erronously huge number of bytes above is
due to the incorrect use of the format descriptor "%ud" instead of just
"%u" in the file "generic/tclCkalloc.c".)
WORKAROUND: Unfortunately, this bug is rather serious. Until it gets
fixed by some kind soul, it is necessary to set the
"-exportselection" option of all tablelist and mclistbox widgets to
false (at least when created with Tk 8.4 under KDE 3.0).
--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de
Joe English
>
>Unfortunately, this is quite easy on a Linux box running KDE 3.0.
>
>METHOD #2: [... deleted]
>METHOD #3: Consider the following simple script:
>
> set win .f
> label $win -text "I am the selection owner.\nClick on <Close>."
> selection own $win
> selection handle $win [list fetchSelection $win]
>
> button .b -text "Close" -command exit
> pack $win .b -padx 10 -pady 5
>
> proc fetchSelection {win offset maxChars} {
> return ""
> }
>
> Running the script with wish8.4 and clicking on the "Close" button
> raises the message "Segmentation fault". This script also shows one
> point that Tablelist and mclistbox have in common: both make use of
> the "selection own" and "selection handle" commands to implement the
> "-exportselection" option.
Do methods 1 and 2 also call [exit], either in a -command callback,
a WM_DELETE_WINDOW handler, or a <Destroy> binding?
If so, this could be related to a different (now-fixed) bug.
Mo Dejong recently (2002-11-14) fixed a number of serious
problems in Tk's shutdown sequence. In particular,
calling [exit] in a <Destroy> binding was a near-surefire
way to cause a crash; and other uses of [exit] while
Tk is in the middle of processing an event could
also mess things up. See Tk Bug #630533 and Bug #620808
for full details.
IIRC, one of the problems had to do with cleaning up
the selection owner window. As a guess, this problem
*might* be exacerbated under KDE because their braindead
clipboard manager operates on the PRIMARY selection
(Note to KDE developers: RTFICCCM, people!)
Could you try the following:
+ Replace [exit] calls with [destroy .] and see
if the problem persists. (With [destroy .] -- the
usual way to terminate a Tk app -- Tk follows a
different code path that doesn't have as many
reentrancy problems.)
+ Run the original versions against the current CVS HEAD
and see if the problem persists.
> [...]
>
>The abnormal termination seems to be caused by a bug in the C-code
>related to the "selection handle" command. After experiencing the
>problem using the ActiveState binary distribution, I compiled Tcl and
>Tk 8.4.1 with the TCL_MEM_DEBUG flag and ran the script again. The
>result was a premature termination of the program with the message
>
> unable to alloc 1633771903d bytes,
> /home/csaba/tcltk/tk8.4.1/generic/tkSelect.c line 1382
OK, now that number just looks totally wrong.
There may be something else going here as well.
Could you file a bug report at SourceForge?
(Assign it to 'jenglish'.)
--Joe English
Csaba Nemethi
In the demo script of method #1 the "Close" button has "-command exit".
The demo script of method #2 is terminated by clicking on the "x" in
the top-left corner of the window; it doesn't have any WM_DELETE_WINDOW
handler or <Destroy> binding.
>
> Could you try the following:
>
> + Replace [exit] calls with [destroy .] and see
> if the problem persists. (With [destroy .] -- the
> usual way to terminate a Tk app -- Tk follows a
> different code path that doesn't have as many
> reentrancy problems.)
>
> + Run the original versions against the current CVS HEAD
> and see if the problem persists.
>
>
By replacing "exit" with "destroy .", or even just [list destroy $win],
the behavior remains unchanged. For this reason, I don't think the
problem is related to Tk's shutdown sequence.
I have also checked out the newest CVS version of Tcl and Tk, and got
the same segmentation fault.
>
>>[...]
>>
>>The abnormal termination seems to be caused by a bug in the C-code
>>related to the "selection handle" command. After experiencing the
>>problem using the ActiveState binary distribution, I compiled Tcl and
>>Tk 8.4.1 with the TCL_MEM_DEBUG flag and ran the script again. The
>>result was a premature termination of the program with the message
>>
>> unable to alloc 1633771903d bytes,
>> /home/csaba/tcltk/tk8.4.1/generic/tkSelect.c line 1382
>
>
> OK, now that number just looks totally wrong.
> There may be something else going here as well.
> Could you file a bug report at SourceForge?
> (Assign it to 'jenglish'.)
>
I suspect that the new (objectified) version of tkSelect.c (or of some
other C file related to selection handling) has a bug that causes the
crash under KDE 3.0. Note that the attempt to allocate 1.6 GB memory
occurs still before the window could become completely visible. This
is probably because the first attempt to retrieve the selection occurs
within a very short time (of one or two seconds). I think that the
following scenario is taking place:
Due to the bug that is still to be found, Tk tries to allocate a huge
amount of memory when invoking the selection handler. This fails, but
the non-debug version isn't aware of the failure. In spite of this,
the selection handler is invoked, and everything seems to work as
expected. Later (at last when destroying the selection owner), Tk
tries to free the memory area of which it thinks that it was allocated,
and this produces a segmentation fault. Under some circumstances this
can happen still before destroying the selection owner window. With
Tablelist I could also produce the crash without clicking on the
"Close" button, by just selecting a lot of items within a short time.
This is, however, not so easy to reproduce as the crash that occurs
when destroying the window.
I will file a bug report at SourceForge as soon as I find some time
for it. Many thanks for your help.
Joe English
>Joe English wrote:
>> Csaba Nemethi wrote:
[ Several ways to crash Tk under KDE 3.0, all involving
[selection handle] scripts ...]
It looks like this is related to Tk's automatic handling
of UTF8_STRING selection targets. If a client registers a
selection handler for the (default) STRING target, Tk 8.4+
automagically adds a duplicate handler for UTF8_STRING.
This is where the bug lies; see Tk Bug #666346 [1] for details.
It should be possible to work around the problem by explicitly
adding a UTF8_STRING handler in all client code:
selection handle $win [list fetchSelection $win]
+ selection handle -type UTF8_STRING [list fetchSelection $win]
The problem is triggered under KDE 3.0 because its "clipboard"
manager [2] is now polling the PRIMARY selection for UTF8_STRING
targets in addition to STRING targets.
[1] <URL: http://sourceforge.net/tracker/index.php?func=detail&aid=666346&group_id=12997&atid=112997 >
[2] ... which doesn't actually manage the clipboard as defined in the ICCCM.
--Joe English
Csaba Nemethi
Joe,
I am very grateful for your help. I have tested your suggestion to
work around the problem by explicitly adding a UTF8_STRING handler,
and I no longer see any "Segmentation fault" messages.
If I understand the C code correctly, it is safer to add the
UTF8_STRING handler *before* adding the one for the type STRING.
Best regards,
Csaba
Reinhard Max
---- snip ----
wm iconbitmap . @16.16.xbm
wm iconify .
---- snap ----
... makes KDE's panel (kicker) crash by saying:
"In file kernel/qpixmap_x11.cpp, line 652: Out of memory"
cu
Reinhard