Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On Fri, Mar 16, 2012 at 1:57 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
> And both machines pass rpm -Va just fine. So the binaries should,
um,
> be the same.
+
> It is a core from yesterday,
There can be difference one of the machines has the files prelink-ed while the
other one does not. prelink runs nightly (/etc/cron.daily/prelink). But it
Thanks!
Prelink is not involved -- I doublechecked. In OLPC builds, we
currently don't prelink due to http://dev.laptop.org/ticket/10898 , we
just don't install prelink and don't run it during OS image creation.
Even back then when we did, we disabled the cronjob :-)
should be already fixed in your GDB version gdb-7.2-52.fc14,
You got that one right :-)
If it helps please contact me off-list, with your disk image. It
assumes the
system generating the core file was not prelinked.
Uploading at
http://dev.laptop.org/~martin/os5rw-brokenimg/Sandisk_1200908562DEN.img
Bear in mind - that'll contain 2 partitions. The 2nd partition is /
but our initrd mounts it, and then chroots into a subdirectory. So
when you mount it, you'll want too look into /versions/run/5/
(WTF is this? Root FS "snapshots" via hardlinked trees. Until we have
btrfs running on these puppies, it's the best update fail-proof
mechanism we have.)
That missing file:
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054
is probably for kernel vDSO (as its name is empty), therefore kernel rpm.
Argh, that could be. But our kernel is a custom built rpm, and we
don't build -debuginfo. Here, have a fistful of my freshly-torn-out
hair.
Now, at the time of this segfault, the dmesg reports a segfault in
python2.7, inside calls to glib... (1) why are we then in the kernel
and (2) why isn't gdb telling us anything about the python/glib part
of the callstack?
still confused -
martin
PS: On a different investigation track we think there may be some
subtle/odd disk corruption that _passes_ rpm -Va and our own
olpc-contents-verify, yet strikes at runtime. Could a subtly corrupt
binary (ie: vmlinuz) lead here?
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff