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

[Petr Machata <pmachata at redhat dot com>]

03.11.2009 23:20, Roland McGrath wrote:
> That suggests that the bookkeeping is going wrong for setting up the
> binary-search lookup table that drives dwfl_addrsegment (segment.c).
> You can probably reproduce it in an isolated test case by extracting
> the sequence of dwfl_report_segment calls made in your scenario, and
> then mocking up a test that does those and then a dwfl_addrsegment call
> to match the bogus results seen inside this core file scenario.

The problem seems to be that l_name, l_ld and l_addr loaded from the 
dump in report_r_debug all end up being zero.

The code in link_map.c says:

/* If content-sniffing already reported a module covering the same area, 
find that existing module to adjust.  The l_ld address is the only one 
we know for sure to be within the module's own segments (its .dynamic). */

With l_ld of 0 we find nothing, dwfl_addrsegment returns -1, and 
report_r_debug then returns with an error.  The comment ("_If_ 
content-sniffing") makes me think that not finding a module is not fact 
the end of the world.  So report_r_debug should tolerate it, and only 
bail out, when dwfl_addrsegment really ended with an error.

My current fix lives on pmachata/dwfl_core_file_report branch.  It 
achieves the above by looking at global dwfl_errno.  Better option, IMO, 
would be to make the dwfl_addrsegment interface richer and return e.g. 
-2 for errors and -1 for module not found.

Please comment,
PM

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.