Re: eu-unstrip -n fails to process a coredump

[Petr Machata <pmachata at redhat dot com>]

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