|
From: Philippe E. <ph...@wa...> - 2002-10-20 16:24:24
|
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 |