Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

Martin Langhoff martin.langhoff at
Thu Mar 15 21:48:36 UTC 2012

Hi John,

thanks for the reply - looping back devel at lfo and devel at llo...

On Thu, Mar 15, 2012 at 5:14 PM, John Gilmore <gnu at> wrote:
> Irreproducible bugs are a real pain.

Indeed --

> Try typing "info files" to gdb and see what sections it sees in the
> core file and in the executable.

I can't make much sense of the output :-/

> Also, you can run objdump -x on the core file, and on the Python
> library, and compare them to see how well the section listings match
> up.  If the various segments are differently sized, then you clearly
> have the wrong debug symbols.
> I also suggest cross-posting to the bug-gdb list, where you'll
> find the GDB developers who know how the separate-debug-symbol stuff
> works.  You might want to make that core file publicly accessible
> in case any other developers want to go digging in it.

I'll hunt those tracks tmw -- you can see the core file, logs from
failing units and more bg info at

> Any local Fedora build wizards may know how to find a -debuginfo
> package via its build-id.

Well, yum should find it ;-) -- but the mystifying thing is yum/rpm
seem to have found the right debuginfo file. gdb disagrees. Who's

> You could also try recompiling python2.7 from its package source, with
> debug symbols, ON the machine where you're debugging.  The catch...

Even if it was reproduceable... I can't make _my_ machine barf.
Faraway machines are barfing left and right in mysterious ways, and we
are trying to get remote access, etc.

But even if I get the remote access, I want to run the currently
failing python under gdb, and again we're going to be with mismatched

> You may have to debug this without symbols.  It looks from your log
> like the program counter and/or stack is off in the weeds.  Did you
> try "bt" to see if any of the stack is accessible?

it doesn't look very useful

Core was generated by `python /usr/bin/sugar-session'.
Program terminated with signal 11, Segmentation fault.
#0  0xa7183e2e in ?? ()
(gdb) bt
#0  0xa7183e2e in ?? ()
#1  0x08f352d0 in ?? ()
#2  0xa6f0ae57 in ?? ()
#3  0x08cea354 in ?? ()
#4  0xa7771878 in ?? ()
#5  0x00000000 in ?? ()

>> "/usr/lib/python2.7 is not at the expected address", and suggests a
> btw, you mistyped there; the message is about /usr/bin/python2.7,
> not /usr/lib/python2.7 (which is a directory).

Sorry, you're right. The fpaste url has the actual output at

 martin.langhoff at
 martin at -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first

More information about the devel mailing list