Re: [peter@os.inf.tu-dresden.de: objdump bug report]

[Philippe E. <ph...@wa...>]

Philippe Elie wrote:
> John Levon wrote:
> 
>> Same cause for the hang the user was seeing in #oprofile recently ?
> 
> 
> I don't think so, our hangs was repeated call to bfd_find_nearest_line.
> 
>  > #0  0x080517e5 in debug_get_real_type (handle=0x80d3258, type=0x81031c8,
>  >     list=0x0) at debug.c:2187
>  > #1  0x080530fb in debug_class_type_samep (info=0x80d3258, t1=0x8107140,
>  >     t2=0x8107838) at debug.c:3462


looking deeper in it, I see it's a miscompilation of binutils by
gcc from 2.95 to 3.0.2 so, on my system,

$ objdump --debugging /lib/ld-linux.so.2

hang. http://sources.redhat.com/ml/binutils/2001-12/msg00372.html

but I can't reproduce it through oprofpp/op_to_source. Looking at
binutils code I can't ensure we are not subject to this bug, but
the reported hang was (iirc) at a different point. Unhopefully
I don't see any bug entry for this once.

I think than:

$ op_time -l -t vspLI

is the best way to check if you get one of these problem (that's
slow don't think it hang if it take less than dozens of seconds)

if someone see this command line hanging determine on what samples
files you hang

$ for f in /var/lib/oprofile/samples/}*; do echo $f && oprofpp -L -t 
vspLI "$f"; done

then report on list the problem, http the samples files and the
corresponding binary.

The hang reported above can be work-around either by upgrading gcc
or by adding at the end of binutils/debug.c:debug_get_real_type() a
dummy call to an empty function. Don't report me this problem i.e.
if gdb report

#0  0x080517e5 in debug_get_real_type (handle=0x80d3258, type=0x81031c8,

you must work around yourself. I'm only interested by the potential hang
in op_bfd::get_linenr()

regards,
Phil