05.11.2009 16:41, Petr Machata wrote:
P.S. Jiri (CCd) mentioned to me on the IRC that he suspects Abrt
core-handling hook might have mangled the dump. The above happens for
the last module in the dump, so one possibility to look into is that the
dump gets truncated. I'll ping you later about that, after I look which
part of the core the zero values actually get read from.
I've taken a look at where do these data come from. It's somewhere in
the middle of the file, so nothing obvious like truncated file.
But I think there is a bug in libdwfl, the library shouldn't find zeroes
there. I instrumented link_map.c: report_r_debug::read_addrs to dump
all read requests, their vaddr, the values it reads, and effective
alignment. The zeroes are read from 0x7fa078e6e800. According to
readelf, that falls inside the following segment:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz
MemSiz Flg Align
LOAD 0x2a08000 0x00007fa078800000 0x0000000000000000
0x700000 0x700000 RW 0x1000
So that's this far in the file:
>> hex (0x2a08000 + 0x7fa078e6e800 - 0x00007fa078800000)
'0x3076800'
od -A x -t x1 gives the following dump in that area of the coredump:
3076600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
3076800 00 00 bf 82 a0 7f 00 00 70 e9 64 76 a0 7f 00 00 <--
3076810 30 e0 df 82 a0 7f 00 00 00 f0 e6 78 a0 7f 00 00
3076820 00 50 03 78 a0 7f 00 00 00 e8 e6 78 a0 7f 00 00
I've written a program that sucks the instrumentation dump in, and
cross-checks it with the actual coredump. In all cases the values
match, i.e. libdwfl reads what's in the file. In this one case where we
get three zeroes, the tool discovers inconsistency.
So there seems to be a bug somewhere deeper. I'll have to disentangle
the callback mess that handles incremental loading of core files to find
what exactly happens.
PM