Debian Bug report logs - #171353
tk crash if widget accessed from wrong thread

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: submit@bugs.debian.org

Subject: tkinter based applications crash

Date: Sun, 1 Dec 2002 20:24:29 +0100

Package: tk8.4
Version: 8.4.1
Severity: important

After the change to build python with tk8.4.1 instead of tk8.3, many
tkinter based applications crash. One of them is

	pydoc -g

same behaviour with python versions 2.1, 2.2 and 2.3 (experimental).
If this is due to the configuration of tk for thread support, we may
need a version without thread support.

$ gdb /usr/bin/python2.2 
GNU gdb 5.2.90_2002-11-20-cvs-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
(gdb) set args /usr/bin/pydoc2.2 -g
(gdb) run
Starting program: /usr/bin/python2.2 /usr/bin/pydoc2.2 -g
(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 
(LWP 29797)]

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 32769 (LWP 29798)]
[New Thread 16386 (LWP 29799)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...[New Thread 32771 
(LWP 29803)]

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 29803)]
0x403493f9 in Tk_FreeGC () from /usr/lib/libtk8.4.so.0
(gdb) bt
#0  0x403493f9 in Tk_FreeGC () from /usr/lib/libtk8.4.so.0
#1  0x40374f74 in TkButtonWorldChanged () from /usr/lib/libtk8.4.so.0
#2  0x40374e96 in Tk_RadiobuttonObjCmd () from /usr/lib/libtk8.4.so.0
#3  0x40374449 in Tk_RadiobuttonObjCmd () from /usr/lib/libtk8.4.so.0
#4  0x404072d4 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#5  0x4040748b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
#6  0x401f709e in _init () from /usr/lib/python2.2/lib-dynload/_tkinter.so
#7  0x080784d6 in PyEval_CallObjectWithKeywords ()
#8  0x08076c76 in _PyExc_Fini ()
#9  0x08077c1d in PyEval_EvalCodeEx ()
#10 0x08079c98 in PyEval_EvalCode ()
#11 0x08076ce1 in _PyExc_Fini ()
#12 0x08077c1d in PyEval_EvalCodeEx ()
#13 0x08079c98 in PyEval_EvalCode ()
#14 0x08076ce1 in _PyExc_Fini ()
#15 0x08077c1d in PyEval_EvalCodeEx ()
#16 0x08079c98 in PyEval_EvalCode ()
#17 0x08076ce1 in _PyExc_Fini ()
#18 0x08077c1d in PyEval_EvalCodeEx ()
#19 0x080bcef9 in PyFunction_New ()
#20 0x080ab0c0 in PyObject_Call ()
#21 0x080b19ff in PyInstance_New ()
#22 0x080ab0c0 in PyObject_Call ()
#23 0x08079d19 in PyEval_EvalCode ()
#24 0x08076cff in _PyExc_Fini ()
#25 0x08077c1d in PyEval_EvalCodeEx ()
#26 0x080bcef9 in PyFunction_New ()
#27 0x080ab0c0 in PyObject_Call ()
#28 0x080b19ff in PyInstance_New ()
#29 0x080ab0c0 in PyObject_Call ()
#30 0x080783ff in PyEval_CallObjectWithKeywords ()
#31 0x080ae20e in PyInstance_New ()
#32 0x080ab0c0 in PyObject_Call ()
#33 0x08079d19 in PyEval_EvalCode ()
#34 0x08076cff in _PyExc_Fini ()
#35 0x08077c1d in PyEval_EvalCodeEx ()
#36 0x080bcef9 in PyFunction_New ()
#37 0x080ab0c0 in PyObject_Call ()
#38 0x080783ff in PyEval_CallObjectWithKeywords ()
#39 0x080ca381 in PyStructSequence_New ()
#40 0x080c89d4 in PyCFunction_Call ()
#41 0x08076c43 in _PyExc_Fini ()
#42 0x08077c1d in PyEval_EvalCodeEx ()
#43 0x08079c98 in PyEval_EvalCode ()
#44 0x08076ce1 in _PyExc_Fini ()
#45 0x08077c1d in PyEval_EvalCodeEx ()
#46 0x080bcef9 in PyFunction_New ()
#47 0x080ab0c0 in PyObject_Call ()
#48 0x080b19ff in PyInstance_New ()
#49 0x080ab0c0 in PyObject_Call ()
#50 0x080783ff in PyEval_CallObjectWithKeywords ()
#51 0x080995a5 in _PyGC_Dump ()
#52 0x4002906f in pthread_start_thread () from /lib/libpthread.so.0
#53 0x400290b5 in pthread_start_thread_event () from /lib/libpthread.so.0

Message #10 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: 171353@bugs.debian.org

Subject: stacktrace

Date: Mon, 2 Dec 2002 10:30:01 +0100

here is a stacktrace with an unstripped tk8.4.1:

$ gdb /usr/bin/python2.3 
GNU gdb 5.2.90_2002-11-20-cvs-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) set args /usr/bin/pydoc2.3 -g
(gdb) run
Starting program: /usr/bin/python2.3 /usr/bin/pydoc2.3 -g
[New Thread 16384 (LWP 30334)]
[New Thread 32769 (LWP 30335)]
[New Thread 16386 (LWP 30336)]
[New Thread 32771 (LWP 30337)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 30337)]
0x404eb3f9 in Tk_FreeGC (display=0x8151878, gc=0x8226318)
    at /home/packages/nmu/tk/tk8.4-8.4.1/unix/../generic/tkGC.c:300
300         if (!dispPtr->gcInit) {
Current language:  auto; currently c
(gdb) info args  
display = (Display *) 0x8151878
gc = 0x8226318
(gdb) info locals
idHashPtr = (Tcl_HashEntry *) 0x10
gcPtr = (TkGC *) 0x81d89e8
dispPtr = (TkDisplay *) 0x0
(gdb) list
295     {
296         Tcl_HashEntry *idHashPtr;
297         register TkGC *gcPtr;
298         TkDisplay *dispPtr = TkGetDisplay(display);
299
300         if (!dispPtr->gcInit) {
301             panic("Tk_FreeGC called before Tk_GetGC");
302         }
303         if (dispPtr->gcInit < 0) {
304             /*
(gdb) bt
#0  0x404eb3f9 in Tk_FreeGC (display=0x8151878, gc=0x8226318)
    at /home/packages/nmu/tk/tk8.4-8.4.1/unix/../generic/tkGC.c:300
#1  0x40516f74 in TkButtonWorldChanged (instanceData=0x81d89e8)
    at /home/packages/nmu/tk/tk8.4-8.4.1/unix/../generic/tkButton.c:1325
#2  0x40516e96 in ConfigureButton (interp=0x818f408, butPtr=0x81d89e8, objc=2, 
    objv=0xbf5fe284)
    at /home/packages/nmu/tk/tk8.4-8.4.1/unix/../generic/tkButton.c:1268
#3  0x40516449 in ButtonWidgetObjCmd (clientData=0x81d89e8, interp=0x818f408, 
    objc=4, objv=0xbf5fe27c)
    at /home/packages/nmu/tk/tk8.4-8.4.1/unix/../generic/tkButton.c:820
#4  0x405a92d4 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#5  0x405a948b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
#6  0x40334e4c in Tkapp_Call (self=0x402e77a0, args=0x82b3278)
    at /home/packages/python2.3/python2.3-2.2.95/Modules/_tkinter.c:915
#7  0x080e2932 in PyCFunction_Call (func=0x40802aec, arg=0x4027b504, 
    kw=0x82ae1b8) at ../Objects/methodobject.c:90
#8  0x080a03f9 in call_function (pp_stack=0xbf5fe488, oparg=0)
    at ../Python/ceval.c:3249
#9  0x0809e9a4 in eval_frame (f=0x814ec2c) at ../Python/ceval.c:2009
#10 0x0809f478 in PyEval_EvalCodeEx (co=0x40307060, globals=0x0, locals=0x0, 
    args=0x815c72c, argcount=4, kws=0x815c73c, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2554
#11 0x080a047b in fast_function (func=0x0, pp_stack=0x0, n=0, na=4, nk=0)
    at ../Python/ceval.c:3297
#12 0x080a02eb in call_function (pp_stack=0xbf5fe618, oparg=0)
    at ../Python/ceval.c:3266
#13 0x0809e9a4 in eval_frame (f=0x815c5d4) at ../Python/ceval.c:2009
#14 0x0809f478 in PyEval_EvalCodeEx (co=0x403070e0, globals=0x0, locals=0x0, 
    args=0x815c720, argcount=1, kws=0x82cda04, kwcount=1, defs=0x40374158, 
    defcount=1, closure=0x0) at ../Python/ceval.c:2554
#15 0x080a047b in fast_function (func=0x0, pp_stack=0x0, n=0, na=1, nk=1)
    at ../Python/ceval.c:3297
#16 0x080a02eb in call_function (pp_stack=0xbf5fe7a8, oparg=0)
    at ../Python/ceval.c:3266
#17 0x0809e9a4 in eval_frame (f=0x82cd8ac) at ../Python/ceval.c:2009
#18 0x0809f478 in PyEval_EvalCodeEx (co=0x402c51a0, globals=0x0, locals=0x0, 
    args=0x815bc14, argcount=2, kws=0x815bc1c, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2554
#19 0x080a047b in fast_function (func=0x0, pp_stack=0x0, n=0, na=2, nk=0)
    at ../Python/ceval.c:3297
#20 0x080a02eb in call_function (pp_stack=0xbf5fe938, oparg=0)
    at ../Python/ceval.c:3266
#21 0x0809e9a4 in eval_frame (f=0x815bac4) at ../Python/ceval.c:2009
#22 0x0809f478 in PyEval_EvalCodeEx (co=0x402c5060, globals=0x0, locals=0x0, 
    args=0x814ea1c, argcount=1, kws=0x814ea20, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2554
#23 0x080a047b in fast_function (func=0x0, pp_stack=0x0, n=0, na=1, nk=0)
    at ../Python/ceval.c:3297
#24 0x080a02eb in call_function (pp_stack=0xbf5feac8, oparg=0)
    at ../Python/ceval.c:3266
#25 0x0809e9a4 in eval_frame (f=0x814e8c4) at ../Python/ceval.c:2009
#26 0x0809f478 in PyEval_EvalCodeEx (co=0x407fabe0, globals=0x0, locals=0x0, 
    args=0x407ffbf0, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    closure=0x0) at ../Python/ceval.c:2554
#27 0x080e2635 in function_call (func=0x40804064, arg=0x407ffbe4, kw=0x0)
    at ../Objects/funcobject.c:473
#28 0x08059d3c in PyObject_Call (func=0x8, arg=0x407ffbe4, kw=0x0)
    at ../Objects/abstract.c:1675
#29 0x0805fd9c in instancemethod_call (func=0x40804064, arg=0x407ffbe4, kw=0x0)
    at ../Objects/classobject.c:2403
#30 0x08059d3c in PyObject_Call (func=0x8, arg=0x407ffbe4, kw=0x0)
    at ../Objects/abstract.c:1675
#31 0x080a0517 in do_call (func=0x407ffb44, pp_stack=0xbf5feef8, na=3, 
    nk=1082129380) at ../Python/ceval.c:3398
#32 0x080a027b in call_function (pp_stack=0xbf5feef8, oparg=1082129380)
    at ../Python/ceval.c:3268
#33 0x0809e9a4 in eval_frame (f=0x8148754) at ../Python/ceval.c:2009
#34 0x0809f478 in PyEval_EvalCodeEx (co=0x402bdf60, globals=0x407ffbe4, 
    locals=0x0, args=0x403847e0, argcount=3, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2554
#35 0x080e2635 in function_call (func=0x408048b4, arg=0x403847d4, kw=0x0)
    at ../Objects/funcobject.c:473
#36 0x08059d3c in PyObject_Call (func=0x8, arg=0x403847d4, kw=0x0)
    at ../Objects/abstract.c:1675
#37 0x0805fd9c in instancemethod_call (func=0x408048b4, arg=0x403847d4, kw=0x0)
    at ../Objects/classobject.c:2403
#38 0x08059d3c in PyObject_Call (func=0x8, arg=0x40802a4c, kw=0x0)
    at ../Objects/abstract.c:1675
#39 0x080a0193 in PyEval_CallObjectWithKeywords (func=0x407ffc34, 
    arg=0x40802a4c, kw=0x0) at ../Python/ceval.c:3156
#40 0x0805ac01 in PyInstance_New (klass=0x408004ac, arg=0x40802a4c, kw=0x0)
    at ../Objects/classobject.c:567
#41 0x08059d3c in PyObject_Call (func=0x8, arg=0x40802a4c, kw=0x0)
    at ../Objects/abstract.c:1675
#42 0x080a0517 in do_call (func=0x408004ac, pp_stack=0xbf5ff398, na=2, 
    nk=1082141260) at ../Python/ceval.c:3398
#43 0x080a027b in call_function (pp_stack=0xbf5ff398, oparg=1082141260)
    at ../Python/ceval.c:3268
#44 0x0809e9a4 in eval_frame (f=0x8146294) at ../Python/ceval.c:2009
#45 0x0809f478 in PyEval_EvalCodeEx (co=0x402c5120, globals=0x40802a4c, 
    locals=0x0, args=0x402b9c18, argcount=3, kws=0x82b1658, kwcount=0, 
    defs=0x402ea8d8, defcount=2, closure=0x0) at ../Python/ceval.c:2554
#46 0x080e2635 in function_call (func=0x402f45dc, arg=0x402b9c0c, 
    kw=0x4039446c) at ../Objects/funcobject.c:473
#47 0x08059d3c in PyObject_Call (func=0x8, arg=0x402b9c0c, kw=0x4039446c)
    at ../Objects/abstract.c:1675
#48 0x080a0193 in PyEval_CallObjectWithKeywords (func=0x402f45dc, 
    arg=0x402b9c0c, kw=0x4039446c) at ../Python/ceval.c:3156
#49 0x08096d1d in builtin_apply (self=0x0, args=0x4030a20c)
    at ../Python/bltinmodule.c:95
#50 0x080e2932 in PyCFunction_Call (func=0x40277cac, arg=0x4030a20c, 
    kw=0x82ae1b8) at ../Objects/methodobject.c:90
#51 0x080a03f9 in call_function (pp_stack=0xbf5ff5b8, oparg=135245184)
    at ../Python/ceval.c:3249
#52 0x0809e9a4 in eval_frame (f=0x814447c) at ../Python/ceval.c:2009
#53 0x0809f478 in PyEval_EvalCodeEx (co=0x4032e560, globals=0x80fad80, 
    locals=0x0, args=0x8135890, argcount=1, kws=0x8135894, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2554
#54 0x080a047b in fast_function (func=0x80fad80, pp_stack=0x80fad80, 
    n=135245184, na=1, nk=0) at ../Python/ceval.c:3297
#55 0x080a02eb in call_function (pp_stack=0xbf5ff748, oparg=135245184)
    at ../Python/ceval.c:3266
#56 0x0809e9a4 in eval_frame (f=0x813573c) at ../Python/ceval.c:2009
#57 0x0809f478 in PyEval_EvalCodeEx (co=0x4032e5e0, globals=0x80fad80, 
    locals=0x0, args=0x4031f578, argcount=1, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2554
#58 0x080e2635 in function_call (func=0x40392d4c, arg=0x4031f56c, kw=0x0)
    at ../Objects/funcobject.c:473
#59 0x08059d3c in PyObject_Call (func=0x8, arg=0x4031f56c, kw=0x0)
    at ../Objects/abstract.c:1675
#60 0x0805fd9c in instancemethod_call (func=0x40392d4c, arg=0x4031f56c, kw=0x0)
    at ../Objects/classobject.c:2403
#61 0x08059d3c in PyObject_Call (func=0x8, arg=0x4026f02c, kw=0x0)
    at ../Objects/abstract.c:1675
#62 0x080a0193 in PyEval_CallObjectWithKeywords (func=0x4038fc0c, 
    arg=0x4026f02c, kw=0x0) at ../Python/ceval.c:3156
#63 0x080cc28e in t_bootstrap (boot_raw=0x82ae1a0)
    at ../Modules/threadmodule.c:180
#64 0x4003a06f in pthread_start_thread () from /lib/libpthread.so.0
#65 0x4003a0b5 in pthread_start_thread_event () from /lib/libpthread.so.0

Message #15 received at 171353@bugs.debian.org (full text, mbox, reply):

From: martin@v.loewis.de (Martin v. Löwis)

To: Matthias Klose <doko@cs.tu-berlin.de>

Cc: 171353@bugs.debian.org

Subject: Re: stacktrace

Date: 02 Dec 2002 10:54:39 +0100

Matthias Klose <doko@cs.tu-berlin.de> writes:

> here is a stacktrace with an unstripped tk8.4.1:

The problem appears to be Tcl's use of thread-local data. TkGetDisplay
is implemented as

TkDisplay *
TkGetDisplay(display)
     Display *display;          /* X's display pointer */
{
    TkDisplay *dispPtr;
    ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
            Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

    for (dispPtr = tsdPtr->displayList; dispPtr != NULL;
	    dispPtr = dispPtr->nextPtr) {
	if (dispPtr->display == display) {
	    break;
	}
    }
    return dispPtr;
}

If Tcl sees a call in a new thread "coming out of nowhere", then
Tcl_GetThreadData will find that there are no thread-local data for
this thread. It will allocate an amount of memory and zero-initialize
it. Then, displayList for that thread will be NULL, and the function
will be NULL.

NULL is a documented return value for TkGetDisplay, but apparently,
Tk_FreeGC does not expect to get NULL, and crashes.

I'm not sure how this is supposed to work. To me, the notion of the
TkDisplay being thread-local sounds inherently broken: In this case,
it means that you can't free a GC in one thread that you have
allocated in another. So I would conclude this to be a bug in Tk.

Regards,
Martin

Message #22 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: Matthias Klose <doko@cs.tu-berlin.de>, 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Mon, 2 Dec 2002 13:55:58 -0800

On Sun, Dec 01, 2002 at 08:24:29PM +0100, Matthias Klose wrote:

> After the change to build python with tk8.4.1 instead of tk8.3

May I suggest that you revert to using 8.3 for now?

> If this is due to the configuration of tk for thread support, we may
> need a version without thread support.

That's obviously a problem -- if I provide two packages, they'll have
to conflict, meaning that certain packages can't be installed with
certain other packages, depending on whether they were linked with the
threaded or the unthreaded version.

As for just removing thread support, that's a possibility, but it
obviously breaks things too (like the new aolserver).  It's a better
option than providing two packages, but very much less than perfect.

The best solution is to fix the bug.  Unfortunately, this may require
some time to track down and come up with a solution that doesn't break
things in its turn.  Thus my suggestion that you stick with 8.3 until
the bugs in the 8.4 threaded version can be fixed.

If I can't find a fix in a reasonable amount of time, I'll probably
revert to no-threads, so I'll warn the aolserver maintainer about this
whole situation.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku

Message #27 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: Chris Waters <xtifr@debian.org>

Cc: 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Mon, 2 Dec 2002 23:21:07 +0100

Chris Waters writes:
> On Sun, Dec 01, 2002 at 08:24:29PM +0100, Matthias Klose wrote:
> 
> > After the change to build python with tk8.4.1 instead of tk8.3
> 
> May I suggest that you revert to using 8.3 for now?

I'll wait a while to see if this can be fixed.

> > If this is due to the configuration of tk for thread support, we may
> > need a version without thread support.
> 
> That's obviously a problem -- if I provide two packages, they'll have
> to conflict, meaning that certain packages can't be installed with
> certain other packages, depending on whether they were linked with the
> threaded or the unthreaded version.
> 
> As for just removing thread support, that's a possibility, but it
> obviously breaks things too (like the new aolserver).  It's a better
> option than providing two packages, but very much less than perfect.
> 
> The best solution is to fix the bug.  Unfortunately, this may require
> some time to track down and come up with a solution that doesn't break
> things in its turn.  Thus my suggestion that you stick with 8.3 until
> the bugs in the 8.4 threaded version can be fixed.

that would mean new uploads for blt, tix8.1, python2.1, python2.2 and
python2.3 ...

> If I can't find a fix in a reasonable amount of time,

To see, if it it's known upstream I tried to find the upstream tk bug
tracking system, but didn't succeed ...

> I'll probably
> revert to no-threads, so I'll warn the aolserver maintainer about this
> whole situation.

another workaround would be to provide a non-threaded
lib{tcl,tk}8.4_pic.a, which can be linked with the python module. Or
is the thread option configured in some header file as well?

Message #32 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: Matthias Klose <doko@cs.tu-berlin.de>

Cc: 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Mon, 2 Dec 2002 16:27:23 -0800

On Mon, Dec 02, 2002 at 11:21:07PM +0100, Matthias Klose wrote:
> Chris Waters writes:

> > May I suggest that you revert to using 8.3 for now?

> I'll wait a while to see if this can be fixed.

Fair enough, that works too.

> To see, if it it's known upstream I tried to find the upstream tk bug
> tracking system, but didn't succeed ...

tcl.sourceforge.net, but unfortunately, sourceforge's BTS sucks
IMO. I'm currently digging through their 200+ open bugs (and if I
can't find anything there, I'll probably have to check "pending" as
well).

> another workaround would be to provide a non-threaded
> lib{tcl,tk}8.4_pic.a, which can be linked with the python module. Or
> is the thread option configured in some header file as well?

Threading is a configure option, so that's possible.  Ugly but possible. :)

cheers
-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku

Message #37 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: 171353@bugs.debian.org, martin@v.loewis.de

Subject: bug report submitted upstream

Date: Fri, 6 Dec 2002 00:01:10 +0100

I submitted this one upstream. Maybe you want to subscribe to the
report.

http://sourceforge.net/tracker/index.php?func=detail&aid=649209&group_id=12997&atid=112997

Message #42 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: Matthias Klose <doko@cs.tu-berlin.de>, 171353@bugs.debian.org

Subject: Re: Bug#171353: bug report submitted upstream

Date: Fri, 6 Dec 2002 22:43:11 -0800

forwarded 171353 tcl.sourceforge.net
thanks

Your upstream bug report is still assigned to "nobody", so maybe I'll
make some noise on comp.lang.tcl and see if anybody there has any
ideas.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku

Message #49 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: Matthias Klose <doko@cs.tu-berlin.de>, 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Tue, 10 Dec 2002 14:44:38 -0800

So, the conclusion of the upstream discussion seems to be that this is
primarily a Tkinter problem.  There's still a bug in Tk (it should
handle the error more gracefully, rather than just crashing), but the
primary flaw is that Tkinter makes invalid assumptions about what it
can do with Tk widgets in arbitrary threads.

For the moment (until Tkinter upstream addresses the problem), I think
the only thing we can do is rebuild Tkinter against tk8.3.

Looking at the mess we've got ourselves into, it looks to me like: blt
supports both 8.3 and 8.4, so it should be ok (and I'm going to go
ahead and adopt it anyway), but tix and the pythons need to be
rebuilt.

What I propose to do is clone this bug, assign the clones to tix and
the pythons, and then downgrade the severity of the original to
normal.  Any objections?

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku

Message #54 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: Chris Waters <xtifr@debian.org>

Cc: 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Wed, 11 Dec 2002 00:27:10 +0100

Chris Waters writes:
> So, the conclusion of the upstream discussion seems to be that this is
> primarily a Tkinter problem.  There's still a bug in Tk (it should
> handle the error more gracefully, rather than just crashing), but the
> primary flaw is that Tkinter makes invalid assumptions about what it
> can do with Tk widgets in arbitrary threads.
> 
> For the moment (until Tkinter upstream addresses the problem), I think
> the only thing we can do is rebuild Tkinter against tk8.3.

no. who garantees, that you don't build tk8.3 with threading enabled? ;-)

the optimal thing would be to build tk8.4 threaded and
unthreaded. what's the problem with this approach?

> Looking at the mess we've got ourselves into, it looks to me like: blt
> supports both 8.3 and 8.4, so it should be ok (and I'm going to go
> ahead and adopt it anyway),

a threaded build can be added as well.

> but tix and the pythons need to be rebuilt.

same for tix. btw, please adopt this as well, if you like.

> What I propose to do is clone this bug, assign the clones to tix and
> the pythons, and then downgrade the severity of the original to
> normal.

>  Any objections?

for the cloning: no. for beeing forced to build with tk8.3: yes

	Matthias

Message #59 received at 171353@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: Matthias Klose <doko@cs.tu-berlin.de>

Cc: 171353@bugs.debian.org

Subject: Re: Bug#171353: tkinter based applications crash

Date: Tue, 10 Dec 2002 16:52:47 -0800

On Wed, Dec 11, 2002 at 12:27:10AM +0100, Matthias Klose wrote:

> no. who garantees, that you don't build tk8.3 with threading enabled? ;-)

I can't -- threading is an 8.4 feature.  It's not even an option in
8.3.  And anyway, if I did that, then I wouldn't have the excuse that
people can use 8.3 if they need a version without threading.  :)

> the optimal thing would be to build tk8.4 threaded and
> unthreaded. what's the problem with this approach?

Archive bloat, package conflicts, lack of time, and maintainance
headaches.  And minimal benefits, since anyone who needs an unthreaded
tcl/tk can use 8.3.  It's just not worth the effort it would take.
I'm not even sure how I'd do it, even if I wanted to, and yes, I've
looked into it (briefly).  Let's just say: there are issues.
Basically, it's not going to happen; at least not in the forseeable
future.

Anyway, I want to REDUCE the number of tk packages in our archives,
not increase it! :)

> btw, please adopt [tix] as well, if you like.

Hmm, I could probably do that.  Let me think about it for a bit.  (I
had just decided to adopt blt when Mike Markley started trying to get
me to adopt libtk-img too, and so I'm feeling a little overwhelmed at
the moment.)

Heck, I don't even like tcl all that much (though I do like tk). :)

> >  Any objections?

> for the cloning: no. for beeing forced to build with tk8.3: yes

Ok, then your alternative is to fix tkinter so that it works with a
threaded 8.4.  Good luck!  :)

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku

Message #70 received at 171353@bugs.debian.org (full text, mbox, reply):

From: martin@v.loewis.de (Martin v. Löwis)

To: 171353@bugs.debian.org

Cc: <doko@cs.tu-berlin.de>

Subject: _tkinter and Tcl threads

Date: 12 Dec 2002 20:07:41 +0100

In revision 1.136 of _tkinter.c, I have added support for a MT Tcl, see

http://mail.python.org/pipermail/python-dev/2002-December/031107.html

This is sufficient to fix the pydoc -g bug; I haven't tried to
reproduce the offlineimap bug.

Because of the size of the change, a backport to Python 2.2 is
unlikely to happen in the near future (if at all).

You might try to use the Python 2.3 _tkinter.c nearly unmodified in
Python 2.2; the only needed change is

#define PyMODINIT_FUNC void

Regards,
Martin

Message #77 received at 171353-close@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@debian.org>

To: 171353-close@bugs.debian.org

Subject: Bug#171353: fixed in tk8.4 8.4.1-2

Date: Mon, 16 Dec 2002 22:02:18 -0500

We believe that the bug you reported is fixed in the latest version of
tk8.4, which is due to be installed in the Debian FTP archive:

tk8.4-dev_8.4.1-2_i386.deb
  to pool/main/t/tk8.4/tk8.4-dev_8.4.1-2_i386.deb
tk8.4-doc_8.4.1-2_all.deb
  to pool/main/t/tk8.4/tk8.4-doc_8.4.1-2_all.deb
tk8.4_8.4.1-2.diff.gz
  to pool/main/t/tk8.4/tk8.4_8.4.1-2.diff.gz
tk8.4_8.4.1-2.dsc
  to pool/main/t/tk8.4/tk8.4_8.4.1-2.dsc
tk8.4_8.4.1-2_i386.deb
  to pool/main/t/tk8.4/tk8.4_8.4.1-2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 171353@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Waters <xtifr@debian.org> (supplier of updated tk8.4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----

Format: 1.7
Date: Mon, 16 Dec 2002 18:08:50 -0800
Source: tk8.4
Binary: tk8.4 tk8.4-dev tk8.4-doc
Architecture: source i386 all
Version: 8.4.1-2
Distribution: unstable
Urgency: low
Maintainer: Chris Waters <xtifr@debian.org>
Changed-By: Chris Waters <xtifr@debian.org>
Description: 
 tk8.4      - Tk toolkit for Tcl and X11, v8.4 - run-time files
 tk8.4-dev  - Tk toolkit for Tcl and X11, v8.4 - development files
 tk8.4-doc  - Tk toolkit for Tcl and X11, v8.4 - manual pages
Closes: 169240 170448 171353
Changes: 
 tk8.4 (8.4.1-2) unstable; urgency=low
 .
   * The -dev package no longer uses a symlink in /usr/share/doc.  Any
     pre-existing link now cleared by preinst.
   * Moved README.Debian to tk8.4 package instead of tk8.4-doc.
   * Updated source location in copyright file (closes: #171353).
   * debian/rules: simplified the logic used to get the .sh file into the
     -dev package.  No longer dependent on the order that dh_movefiles
     processes thepackages, and no longer uses obscure globbing magic.
   * Include the actual upstream changelog file, as well as the file named
     "changes" (which is more of a user-oriented description).
   * Move images to /usr/share, with symlink from /usr/lib so things don't
     break.  (Check that symlink in preinst too.)  This may or may not make
     us FHS-compliant, but at least it shuts lintian up.  :)
   * Changed the font selection algorithm to prefer the first best-match,
     not the last.  Patch from Massimo Dal Zotto.
   * Applied new Hurd patch from Robert Millan (closes: #170448).
   * Added conflicts for old libtk-img (closes: #169240).
Files: 
 f348ed05d3a551455a63978edffde97e 714 libs optional tk8.4_8.4.1-2.dsc
 810b408d8be36f9737b87401cb30a404 14852 libs optional tk8.4_8.4.1-2.diff.gz
 4afc7486188a11e73d25207c31a8375d 741912 doc optional tk8.4-doc_8.4.1-2_all.deb
 71c00c92c741816ab660b1490b132387 873538 libs optional tk8.4_8.4.1-2_i386.deb
 212f76d823c285eacad6293e45b121cc 680082 devel optional tk8.4-dev_8.4.1-2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUBPf6LszZs0/7rwRsBAQF0TgQAqrJ2PVphNCO4afDvChcxkDDRlf8vKDt7
XQvAHOlmfRz0RqU8DfbX//DM3AP/9XeBXIyehgEWRfFBQTS02SHO440f+9c8LJWC
uhKGrJ45iJTIYFrk64PwteCYsrIR04Ykxe9Fp0vPlvJqlbj2eE+DU5lpH50L1Ft2
jPsH3BQGE+U=
=Vi67
-----END PGP SIGNATURE-----

Message #84 received at 171353-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 162105-done@bugs.debian.org,171353-done@bugs.debian.org,265402-done@bugs.debian.org,287807-done@bugs.debian.org,295649-done@bugs.debian.org,342127-done@bugs.debian.org,384720-done@bugs.debian.org,695445-done@bugs.debian.org,734837-done@bugs.debian.org,818755-done@bugs.debian.org,

Cc: tk8.4@packages.debian.org, tk8.4@packages.qa.debian.org

Subject: Bug#858681: Removed package(s) from unstable

Date: Tue, 04 Apr 2017 20:06:39 +0000

Version: 8.4.20-8+rm

Dear submitter,

as the package tk8.4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/858681

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Chris Lamb (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.