Submitted by: Eric Hassold
OperatingSystem: Linux (Red Hat 5.0+ on Intel)
Synopsis: Tk8.1 strongly unstable with --enable-thread
Not reproductible (random hang)
our Tcl/Tk/C application (about 100.000 lines of C, 20.000 of Tcl),
compiled with thread-enabled Tcl/Tk 8.1 Final, hangs frequently, and
randomly (that is, several runs gives errors not at the same moment).
When it occurs, all windows frozen, so no stack trace available. Our
application is *NOT* multi-threaded, and doesn't modify or redefine any
of the core Tcl/Tk routines. It works fine with 8.0.X, and with 8.1
Final compiled *without* --enable-thread
We admit this description is not precise enough to be very helpful for
Tcl/Tk developpers. It shoud be considered more as a "user feedback"
than a "bug report" (we might investigate more deeply in the coming
days/weeks). The question is "should thread-safety" still be considered
as Beta ? has anyone else experiment such problem (maybe on others
platforms) ? or are they any special rules to respect when linking with
multi-threads enabled Tcl/Tk libraires, even if our app. is not (yet)
Are you using an mult-processor machine?
If anyone else sees problems like this, PLEASE send us a sample
or try to find the problem yourself. It's probably caused
by a mutex being held by one thread when it should have been
-- Scott Redman
-- Scriptics Corp.
Tcl/Tk8.1 Final are much stable than 8.1b3 with -enable-thread on
Many hangs on 8.1b3 are disappeared. It is a really stable software.
One problem is to modify C extension. Tcl8.1 C APIs changed a lot.
The entire regular expression C APIs are new. And no backward
for them. But it worth to upgrade to 8.1.
> we plan to diagnose the problem more precisely in the coming days (probably
> at the end of the week) and hope we will be able to give you more detailed
> informations or extract some piece of code, which might be more useful for
> you. Let me recall that the purpose of the original message was just to
> share our very first experience using final 8.1 with the Tcl communauty.
> BTW, thanks to all the Scriptics team for the great job they did to offer us
> this new release, and to your very fast answers to our bug reports.
Chang LI, Neatware
>There may be some bugs in the notifier code for Tcl and/or Tk.
>The best way to fix these problems is to either debug them yourselves,
>or send us a sample that reproduces the hang.
>Are you using an mult-processor machine?
No, the tests were run on a single processor machine.
1. it's different code for the Tcl_Notifier
2. Windows doesn't have a true Mutex, so a single thread (with one
mutex) can't block itself. On Unix, if a thread doesn't unlock
a mutex, then tries to lock it again, it will hang (probably the cause
of this bug).
3. There are so many different versions of Unix, with so
many implementations of pthreads, it's a little tougher to
keep them all straight.
Eric has sent me a sample of code that I can work with. Again, I encourage
everyone to attempt to find a sample when reporting a problem in the
thread-enabled Tcl/Tk. We also need to know what type of machine, os,
os version, and number of processors. Thanks in advance...
Chang LI wrote:
> Eric Hassold wrote:
> Tcl/Tk8.1 Final are much stable than 8.1b3 with -enable-thread on
> Many hangs on 8.1b3 are disappeared. It is a really stable software.
> One problem is to modify C extension. Tcl8.1 C APIs changed a lot.
> The entire regular expression C APIs are new. And no backward
> for them. But it worth to upgrade to 8.1.
> > we plan to diagnose the problem more precisely in the coming days (probably
> > at the end of the week) and hope we will be able to give you more detailed
> > informations or extract some piece of code, which might be more useful for
> > you. Let me recall that the purpose of the original message was just to
> > share our very first experience using final 8.1 with the Tcl communauty.
> > BTW, thanks to all the Scriptics team for the great job they did to offer us
> > this new release, and to your very fast answers to our bug reports.
> > Eric.
After 1 hour useless Tcl/Tk debugging with my favourite ddd, finally got the
answer to what is finally not really a Tk problem.
I was wondering why the simple script I sent to you was hanging when run
from a C app, and not from my wish interpreter. A simple ldd on both on both
executable (see dump below) gave me the answer. Both apps were linked with
the same libs, but as our "old" configure/Makefiles was not explictly
mentionning the -lpthread on the linker command line, the dynamic loader was
of course detecting the pthread was required by tcl8.1 and tk8.1, and
automatically loading it *before* the libc, making the runtime particulary
instable (those kind of lovely bugs occuring randomly, in system librairies
for which no debug information is available..very pleasant :-).
So, the conclusion : (at least on Linux systems), any TclTk application
linked with the thread-enabled TclTk librairies, no matter if they are
multi-threaded or not, have to be linked by mentionning *explicitly*
the -lpthread argument, without trusting the dynamic loader automatic
resolution. This has nothing to do with a TclTk bug, but maybe does it worth
to be mentionned somewhere in the README, manual or whatever. I can easily
guess most people developping multi-threaded apps will instinctively add
the -lpthread argument to the linker parameters, but I also guess most
people just migrating their C/Tcl/Tk apps from 8.0 to 8.1 (fo rexample for
the multi-lingual support) will not so naturally modify their Makefiles,
particulary if it compiles apparently perfectly well, and that the
instability occurs only on some obscur conditions (extensive use of the
"after" and "update" in a very particular part opf our code was for us the
Thanks again to Scott for his answers.
Sermotec - France
libtk8.1.so => /usr/local/tcltk/lib/libtk8.1.so (0x40000000)
libtcl8.1.so => /usr/local/tcltk/lib/libtcl8.1.so (0x400a9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40126000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40133000)
libdl.so.2 => /lib/libdl.so.2 (0x401ca000)
libm.so.6 => /lib/libm.so.6 (0x401cd000)
libc.so.6 => /lib/libc.so.6 (0x401e6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
libtk8.1.so => /usr/local/lib/libtk8.1.so (0x40000000)
libtcl8.1.so => /usr/local/lib/libtcl8.1.so (0x400a9000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40124000)
libdl.so.2 => /lib/libdl.so.2 (0x401bc000)
libm.so.6 => /lib/libm.so.6 (0x401bf000)
libc.so.6 => /lib/libc.so.6 (0x401d8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4027d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
Scott Redman a écrit dans le message <372F23C4...@scriptics.com>...