Python segfault: possible cause and solution/workaround
bas at bmail.ru
Sun Aug 21 03:35:00 EDT 2011
On Sat, 20 Aug 2011, David Kuehling wrote:
> 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/readline.so . When that readline.so 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 libncursesw.so.5 is loaded, but libncurses.so.5 (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 (http://invisible-island.net/ncurses/ncurses.faq.html, "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
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 libncurses.so.5 into libreadline.so.5 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/readline.so . 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: http://dvdkhlng.users.sourceforge.net/dk.gpg
> Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
More information about the discussion