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

[Edgar E. Iglesias]

On Fri, Nov 02, 2012 at 06:07:50PM +0100, Sedat Dilek wrote:
> This happens with latest ltrace-git...
> 
> DEBUG: dict.c:160: dict_find_entry()
> DEBUG: breakpoints.c:248: delete_breakpoint(pid=2290, addr=0x400640)
> DEBUG: dict.c:160: dict_find_entry()
> DEBUG: breakpoint.c:133: disable_breakpoint: pid=2290, addr=0x400640,
> symbol=(null)
> DEBUG: breakpoint.c:99: arch_disable_breakpoint: pid=2290,
> addr=0x400640, symbol=(null)
> DEBUG: proc.c:927: proc_remove_breakpoint(pid=2290, (null)@0x400640)
> DEBUG: dict.c:132: dict_remove(0x400640)
> DEBUG: proc.c:593: linkmap_init(2290, dyn_addr=0x400160)
> DEBUG: proc.c:324: find_dynamic_entry()
> DEBUG: proc.c:541: load_debug_struct
> DEBUG: breakpoints.c:210: insert_breakpoint(pid=2290, addr=0x2aaa8b94,
> symbol=NULL)
> DEBUG: dict.c:160: dict_find_entry()
> DEBUG: proc.c:905: proc_add_breakpoint(pid=2290, (null)@0x2aaa8b94)
> DEBUG: dict.c:160: dict_find_entry()
> DEBUG: dict.c:98: dict_enter()
> DEBUG: dict.c:124: new dict entry at 0x4b8590[843]: (0x2aaa8b94,0x492160)
> DEBUG: breakpoint.c:85: enable_breakpoint: pid=2290, addr=0x2aaa8b94,
> symbol=(null)
> DEBUG: breakpoint.c:48: arch_enable_breakpoint: pid=2290,
> addr=0x2aaa8b94, symbol=(null)
> DEBUG: proc.c:474: crawl_linkmap()
> DEBUG: ltrace-elf.c:342: do_init_elf(filename=./a.out)
> DEBUG: ltrace-elf.c:343: Reading ELF from ./a.out...
> DEBUG: ltrace-elf.c:476: ./a.out 4 PLT relocations
> DEBUG: ltrace-elf.c:488: do_close_elf()
> DEBUG: proc.c:831: added library a.out at 0x400000 (./a.out) to 2290
> DEBUG: dict.c:160: dict_find_entry()
> ./ltrace: proc.c: 755: breakpoint_for_symbol: Assertion `bp->libsym ==
> ((void *)0)' failed.
> 
> For more details see attached log and howto.

Hi,

Thanks for the report.

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.

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.

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.

Best regards,
Edgar