Segfault with tktreectrl on python-2.5 on linux

[klappnase]

Hello,

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]

Hi,

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]

Anton Hartl schrieb:

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]

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]

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