Python segfault: possible cause and solution/workaround

David Kuehling dvdkhlng at
Sat Aug 20 17:11:22 EDT 2011


did some remote debugging on the python that is shipped with the 08-19
firmware.  Without debug info, just on the asm level, but looks like the
cause is pretty clear:

Crash happens in libreadline.  It jumps to address 0 after loading the
branch target out of the plt ('lw t9,...(gp)').  This looks very much
like an unresolved symbol in libreadline, where the dynamic linker just
left a 0-pointer.  Libreadline is loaded dynamically via
/usr/lib/python2.6/lib-dynload/ .  When that does
a dlopen() with lazy symbol resolving, then 0-pointers on unresolved
symbols would be quite natural.

Looking at the libraries that where loaded at the time of the crash, I
can see that is loaded, but (without
'w') is not.  I think this is needed by libreadline.  Looks like the
dynamic linker doesn't know how to resolve that dependency at run-time.
Explicitely linking into may fix that.
Note that the dynamic loader on openwrt seems to differ from the one
used on mainstream linuxes (uclibc vs. libc issue?).  Saw these problems
with gforth, too.

As a workaround for now, it is sufficient to just remove (or
move/rename) /usr/lib/python2.6/lib-dynload/ .  Just did that
and now python works for me.  Albeit without proper command editor.

Maybe we could just patch the next release firmware this way to enable a
(slightly crippled) python.


GnuPG public key:
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the discussion mailing list