[Ltrace-devel] ./ltrace: proc.c: 755: breakpoint_for_symbol: Assertion `bp->libsym == ((void *)0)' failed.

Petr Machata pmachata at redhat.com
Fri Nov 2 22:58:52 UTC 2012


"Edgar E. Iglesias" <edgar.iglesias at gmail.com> writes:

> On Fri, Nov 02, 2012 at 06:07:50PM +0100, Sedat Dilek wrote:
>> This happens with latest ltrace-git...
>>
>> ./ltrace: proc.c: 755: breakpoint_for_symbol: Assertion `bp->libsym ==
>> ((void *)0)' failed.
>> 
> I've seen this bug, and I'm actually inclined to think that the assert
> should go away and that we instead should somehow just not use that
> break point. But not sure, maybe Petr has more input on this.

If you assign more than one symbol to a breakpoint, and that breakpoint
hits, there's no way to tell which of the symbols actually hit.  So
there's no point storing more than one symbol to a breakpoint.  We could
still drop the assert and just ignore the symbol, as you write.

What might make sense is having several breakpoint handlers per
breakpoint, so that ltrace allows several service breakpoints per
address.  Software singlestepping in particular should work well even if
it steps over another breakpoint, service or not.  (As should normal
singlestepping, and I'm not positive that it does, but that's a
different can of worms.)

> The issue I've seen is with weak symbols that are made to point to
> other symbols. I think, I saw it with strlen IIRC. In our glibc,
> strlen points resolves to the same addr as __strlen but it's got
> it's own PLT entry and symbol.

Hmm, how about having two PLT slots, each for a different symbol, but
those symbols are aliases in the target library.  Ltrace filters
aliases, but only for purposes of -x.  For -e there's no way to tell
that they end up being aliases.  And normally you don't care anyway, but
on MIPS breakpoints are put not to PLT slots, but to destination
addresses.  That's how you end up needing two breakpoints on the same
address.  Could it be the cause?

If yes, then the reproducer is as simple as -e func -x func.

> I've got a local patch for it, but I unfortunately I haven't had much
> time lately to look at it further. My plan was to create a test case
> that hopefully can trig the issue on x86 aswell. Then we can work out
> a solution from there.

I guess on x86, one could trigger the same by IFUNC symbols, but those
will need to be supported at all in the first place.

Thanks,
PM



More information about the Ltrace-devel mailing list