Python segfault: possible cause and solution/workaround

kyak bas at
Sun Aug 21 03:35:00 EDT 2011

Hi David,

On Sat, 20 Aug 2011, David Kuehling wrote:

> Hi,
> 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

libncursesw stands for the "wide" version of ncurses, i.e., supporting 
two-byte characters. It doesn't need to have "regular" version of ncurses 
loaded because the "wide" version is backwards compatible with the 
"regular" one (, "The 
ncurses and ncursesw libraries are reasonably source-compatible. That is, 
an application written for "ncurses" will build with "ncursesw".").

I just want to clarify that it doesn't have anything to do with the 
letter "w" :)

David, you did a great find. So I searched for keywords and here's
what i found:
It started here:
(there are other related discussions for dynamic linker, python, readline 
and ncurses if you search their mailing lists :)

So at the end, seems that the readline needs to be patched for that.

David, if you're going to do that 
(, please 
force the link to wide ncurses, so one would be able to type wide-char in 
python command line :)

> 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.
> cheers,
> David
> -- 
> GnuPG public key:
> Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

More information about the discussion mailing list