By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,033 Members | 1,952 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,033 IT Pros & Developers. It's quick & easy.

Segfault with tktreectrl on python-2.5 on linux

P: n/a
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

Jan 15 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hi,

On 2007-01-15, klappnase <kl*******@web.dewrote:
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

Jan 15 '07 #2

P: n/a
Anton Hartl schrieb:

<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

Jan 16 '07 #3

P: n/a
On 2007-01-16, klappnase <kl*******@web.dewrote:
>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!
Jan 16 '07 #4

P: n/a

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

Jan 16 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.