Hi John, thanks for the reply - looping back devel@lfo and devel@llo... On Thu, Mar 15, 2012 at 5:14 PM, John Gilmore <gnu@xxxxxxxx> 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 :-/ http://fpaste.org/R457/ > 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 http://dev.laptop.org/ticket/11698 > 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 right? > 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 debuginfos. > 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 http://fpaste.org/YqGv/ m -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
