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

[Edgar E. Iglesias]

On Thu, Nov 08, 2012 at 04:27:54PM +0100, Sedat Dilek wrote:
> On Thu, Nov 8, 2012 at 4:08 PM, Edgar E. Iglesias
> <edgar.iglesias at gmail.com> wrote:
> > On Thu, Nov 08, 2012 at 03:53:26PM +0100, Sedat Dilek wrote:
> >> 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...
> >
> >
> > Hi Sedak,
> >
> > This was the latest patch in my tree when I had to stop. I need to go
> > through this before something can be submitted. But if you want to try it
> > out, that would help.
> >
> 
> Test results attached.

Thanks. Looks like it passed ok no?

Cheers