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

[Sedat Dilek]

On Fri, Nov 2, 2012 at 11:58 PM, Petr Machata <pmachata at redhat.com> wrote:
> "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.
>

Hi Edgar,

Any news or even patch(es) around for this issue?

I re-tested with ltrace-0.7.0-git1584cfc again to see if any new
changes did or did not break build on MIPSEL (own toolchain built with
Freetz build-system).
Building is fine, but the reported issue still remains.

I can only help with more testing these days...

- Sedat -

> Thanks,
> PM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-L-x-main-debug-71-20121108.txt.gz
Type: application/x-gzip
Size: 5113 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20121108/d236064d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-L-x-main-debug-71-20121108.txt.gz.sha256sum
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20121108/d236064d/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-0.7.0-git-for-freetz-devel.diff.gz
Type: application/x-gzip
Size: 12795 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20121108/d236064d/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-0.7.0-git-for-freetz-devel.diff.gz.sha256sum
Type: application/octet-stream
Size: 107 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20121108/d236064d/attachment-0003.obj>