Segfault with tktreectrl on python-2.5 on linux

Anton Hartl anton.hartl at gmail.com
Mon Jan 15 14:34:46 EST 2007


Hi,

On 2007-01-15, klappnase <klappnase at 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




More information about the Python-list mailing list