Segfault with tktreectrl on python-2.5 on linux
klappnase
I use the tktreectrl Tk extension (http://tktreectrl.sourceforge.net)
through the python wrapper module
(http://klappnase.zexxo.net/TkinterTreectrl/index.html).
With python-2.5 it seems that each time some text is inserted into the
treectrl widget a segfault occurs (on linux, on windows2000 it seemed
to work).
Some people sent me mail describing the same problem, so I think it is
not a problem with my installation of python-2.5. The treectrl widget
itself works well when running from Tcl or from python2.4, so i suspect
that it is a bug in python-2.5.
Below the output from gdb when running the dirtree demo from the
TkinterTreectrl package:
(gdb) run
Starting program: /usr/local/bin/python2.5
/home/pingu/projekte/TkinterTreectrl/TkinterTreectrl-0.6/demo/dirtree.py
[Thread debugging using libthread_db enabled]
[New Thread -1209842944 (LWP 21831)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209842944 (LWP 21831)]
block_alloc (b=0x1, size=16) at Python/pyarena.c:109
109 if (b->ab_offset + size > b->ab_size) {
(gdb) bt
#0 block_alloc (b=0x1, size=16) at Python/pyarena.c:109
#1 0x080d829e in PyArena_Malloc (arena=0x82b2790, size=16) at
Python/pyarena.c:192
#2 0x081129ca in Ellipsis (arena=0x10) at Python/Python-ast.c:1764
#3 0xb77731ef in DisplayProcText () from
/usr/lib/treectrl2.2/libtreectrl2.2.so
Any ideas?
Regards
Michael
Anton Hartl
On 2007-01-15, klappnase <klap...@web.de> wrote:
> Some people sent me mail describing the same problem, so I think it is
> not a problem with my installation of python-2.5. The treectrl widget
> itself works well when running from Tcl or from python2.4, so i suspect
> that it is a bug in python-2.5.
> Below the output from gdb when running the dirtree demo from the
> TkinterTreectrl package:
>
> (gdb) run
> Starting program: /usr/local/bin/python2.5
> /home/pingu/projekte/TkinterTreectrl/TkinterTreectrl-0.6/demo/dirtree.py
> [Thread debugging using libthread_db enabled]
> [New Thread -1209842944 (LWP 21831)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209842944 (LWP 21831)]
> block_alloc (b=0x1, size=16) at Python/pyarena.c:109
> 109 if (b->ab_offset + size > b->ab_size) {
> (gdb) bt
> #0 block_alloc (b=0x1, size=16) at Python/pyarena.c:109
> #1 0x080d829e in PyArena_Malloc (arena=0x82b2790, size=16) at
> Python/pyarena.c:192
> #2 0x081129ca in Ellipsis (arena=0x10) at Python/Python-ast.c:1764
> #3 0xb77731ef in DisplayProcText () from
> /usr/lib/treectrl2.2/libtreectrl2.2.so
>
> Any ideas?
Yes. And a solution as well :)
Here is the story:
- libpython2.5.so contains a global symbol "Ellipsis"; this is
new in 2.5 and came in with the new AST/compiler code
- starting python2.5 loads libpython2.5.so (obviously)
- now you do something like:
tk.call("package", "require", "tktreectrl")
this loads libtktreectrl2.2.so
- libtktreectrl2.2.so contains a global symbol "Ellipsis"
- and now disaster happens: references in libtktreectrl2.2.so
to "Ellipsis" are NOT resolved to the "Ellipsis" symbol
in libtktreectrl2.2.so but rather to the "Ellipsis" symbol
in libpython2.5.so
- this is not what you want, but is correct behaviour of
symbol resolution in shared shared libraries (and is
equivalant to the behaviour with static libs btw)
Solutions:
a) convince Python developers to prefix ALL new (wrt. 2.5)
global symbols with a prefix like "_PyAST_" or equivalent;
this would be consistent with how it is done anyway,
unfortunately the new AST symbols deviate from this practise
(there are symbols like "Assert", "If", "Then", ...)
or b) apply an equivalent rule to the global symbols in
tktreectrl that are global by accident, i.e. because
of the way the library is structured and built
Best Regards,
Anton
klappnase
<snip>
>
> Solutions:
>
> a) convince Python developers to prefix ALL new (wrt. 2.5)
> global symbols with a prefix like "_PyAST_" or equivalent;
> this would be consistent with how it is done anyway,
> unfortunately the new AST symbols deviate from this practise
> (there are symbols like "Assert", "If", "Then", ...)
>
> or b) apply an equivalent rule to the global symbols in
> tktreectrl that are global by accident, i.e. because
> of the way the library is structured and built
>
Anton, you're cool,
actually renaming Ellipsis to Py_Ast_Ellipsis in ast.c and Python-ast.c
seems to fix this.
What I don't understand, isn't it very likely that such things will
happen when names like "Ellipsis" or "Slice" and "Index" (which I also
found in Python-ast.c) are being used, or are the treectrl people doing
something they should avoid?
I think the answer to this might be important when deciding to whom I
should send a bug report :)
Thanks and best regards
Michael
Anton Hartl
>> Solutions:
>>
>> a) convince Python developers to prefix ALL new (wrt. 2.5)
>> global symbols with a prefix like "_PyAST_" or equivalent;
>> this would be consistent with how it is done anyway,
>> unfortunately the new AST symbols deviate from this practise
>> (there are symbols like "Assert", "If", "Then", ...)
>>
>> or b) apply an equivalent rule to the global symbols in
>> tktreectrl that are global by accident, i.e. because
>> of the way the library is structured and built
>>
>
> Anton, you're cool,
Well :) understanding this bug required a looong stare at the
gdb stacktrace and a short experiment with loading shared libraries
to verify my understanding with a simple example.
>
> actually renaming Ellipsis to Py_Ast_Ellipsis in ast.c and Python-ast.c
> seems to fix this.
Alternatively renaming Ellipsis to TkTc_Ellipsis in tktreectrl
works too; that's what I did :)
> What I don't understand, isn't it very likely that such things will
> happen when names like "Ellipsis" or "Slice" and "Index" (which I also
> found in Python-ast.c) are being used, or are the treectrl people doing
> something they should avoid?
IMHO global symbols that do not actually have any use outside
the respective library should follow a naming convention that
minimizes the probablity of name clashes like this. I.e. both
the new AST symbols in Python 2.5 and the global symbols in
tktreectrl should be prefixed appropriately.
> I think the answer to this might be important when deciding to whom I
> should send a bug report :)
The bug report should go to both; I actually contacted Jeremy Hylton
as a main contributor of the new AST code two weeks ago but didn't
get any response.
Regards,
Anton
PS
Thanks for your work on TkinterTreectrl!
klappnase
Anton Hartl schrieb:
> The bug report should go to both; I actually contacted Jeremy Hylton
> as a main contributor of the new AST code two weeks ago but didn't
> get any response.
>
Ok, I submitted bug reports on both the tktreectrl and the python
sourceforge pages.
Now I'll have a nice cup of tea and see what happens :)
Regards
Michael