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@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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
