[Ltrace-devel] Getting prototypes from debug information

Wed Apr 30 21:03:57 UTC 2014

Dima Kogan <lists at dima.secretsauce.net> writes:

> I think this all works sufficiently now for me to get the details ironed
> out (memory, error handling), so I'm going to be looking at that next.

Hi.

I went back and reworked the memory management and error handling. The
code is pushed into the same tree as before. Things should be correct
now, and appear to work reasonably well. Valgrind still finds memory
leaks; most were present before. Notable new ones:

1. filter_matches_symbol() and dwlf is leaking. Every time I call these
we leak a bit. The dwfl is out of our hands, but the
filter_matches_symbol() maybe could be plugged:

  ==22679== 16 bytes in 1 blocks are still reachable in loss record 70 of 152
  ==22679==    at 0x4C274A0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==22679==    by 0x56533A4: register_state (regex_internal.c:972)
  ==22679==    by 0x5656790: re_acquire_state_context (regex_internal.c:1726)
  ==22679==    by 0x55AE338: build_trtable (regexec.c:3439)
  ==22679==    by 0x565C12F: re_search_internal (regexec.c:2307)
  ==22679==    by 0x56609D4: regexec@@GLIBC_2.3.4 (regexec.c:253)
  ==22679==    by 0x408F6F: re_match_or_error (filter.c:114)
  ==22679==    by 0x409194: filter_matches_symbol (filter.c:183)
  ==22679==    by 0x42B131: import_subprogram (dwarf_prototypes.c:887)
  ==22679==    by 0x42B3D7: process_die_compileunit (dwarf_prototypes.c:930)
  ==22679==    by 0x42B4EE: import (dwarf_prototypes.c:953)
  ==22679==    by 0x42B67A: import_DWARF_prototypes (dwarf_prototypes.c:981)

  ==22679== 16 bytes in 1 blocks are indirectly lost in loss record 73 of 152
  ==22679==    at 0x4C297AE: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==22679==    by 0x5157B6B: ??? (in /usr/lib/x86_64-linux-gnu/libdw-0.158.so)
  ==22679==    by 0x5157CEC: ??? (in /usr/lib/x86_64-linux-gnu/libdw-0.158.so)
  ==22679==    by 0x51580A0: dwfl_nextcu (in /usr/lib/x86_64-linux-gnu/libdw-0.158.so)
  ==22679==    by 0x42B558: import (dwarf_prototypes.c:951)
  ==22679==    by 0x42B67A: import_DWARF_prototypes (dwarf_prototypes.c:981)
  ==22679==    by 0x41CD04: library_get_prototype (output.c:222)
  ==22679==    by 0x41CDC1: find_proto_cb (output.c:245)
  ==22679==    by 0x407003: proc_each_library (proc.c:1005)
  ==22679==    by 0x41CE84: lookup_symbol_prototype (output.c:261)
  ==22679==    by 0x41D888: output_left (output.c:549)
  ==22679==    by 0x41C0E1: handle_breakpoint (handle_event.c:756)

2. The prototypes my DWARF parser produces leak a bit. Those are stored
with protolib_add_prototype(). Is that sufficient? I.e. do protolibs
eventually clean out their prototypes?

  ==22679== 624 bytes in 13 blocks are definitely lost in loss record 142 of 152
  ==22679==    at 0x4C29590: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==22679==    by 0x42AA08: get_prototype (dwarf_prototypes.c:787)
  ==22679==    by 0x42B281: import_subprogram (dwarf_prototypes.c:903)
  ==22679==    by 0x42B3D7: process_die_compileunit (dwarf_prototypes.c:930)
  ==22679==    by 0x42B4EE: import (dwarf_prototypes.c:953)
  ==22679==    by 0x42B67A: import_DWARF_prototypes (dwarf_prototypes.c:981)
  ==22679==    by 0x41CD04: library_get_prototype (output.c:222)
  ==22679==    by 0x41CDC1: find_proto_cb (output.c:245)
  ==22679==    by 0x407003: proc_each_library (proc.c:1005)
  ==22679==    by 0x41CE84: lookup_symbol_prototype (output.c:261)
  ==22679==    by 0x41D888: output_left (output.c:549)
  ==22679==    by 0x41C0E1: handle_breakpoint (handle_event.c:756)

  ==22679== 448 bytes in 8 blocks are definitely lost in loss record 140 of 152
  ==22679==    at 0x4C29590: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==22679==    by 0x42AB14: get_prototype (dwarf_prototypes.c:801)
  ==22679==    by 0x42B281: import_subprogram (dwarf_prototypes.c:903)
  ==22679==    by 0x42B3D7: process_die_compileunit (dwarf_prototypes.c:930)
  ==22679==    by 0x42B4EE: import (dwarf_prototypes.c:953)
  ==22679==    by 0x42B67A: import_DWARF_prototypes (dwarf_prototypes.c:981)
  ==22679==    by 0x41CD04: library_get_prototype (output.c:222)
  ==22679==    by 0x41CDC1: find_proto_cb (output.c:245)
  ==22679==    by 0x407003: proc_each_library (proc.c:1005)
  ==22679==    by 0x41CE84: lookup_symbol_prototype (output.c:261)
  ==22679==    by 0x41D888: output_left (output.c:549)
  ==22679==    by 0x41C0E1: handle_breakpoint (handle_event.c:756)

I'm not sure how much we care, however. These should all be one-time
allocations, and everything is cleared out when the process exits
anyway.

Things work nicely with my test lib. As usual, trying to test on
programs that are "in the wild" is troublesome. Maybe you can help.
First issue:

 dima at shorty:~/projects/ltrace$ ./ltrace -l libc.so.6 sleep 1 |& grep nanosleep

 sleep->nanosleep(0x7fffc23b5d00, 0, 0, 0)                              = 0

Note that nanosleep didn't get its prototype parsed even though the
DWARF is available. It turns out that the exported symbol is indeed
called "nanosleep", but the DWARF definitions have a DW_AT_name of
"__nanosleep" and a DW_AT_linkage_name "__GI___nanosleep". The DWARF has
no mention at all of "nanosleep", which is the main issue. How can we
infer a connection between those two?

Another issue. I have debug symbols for libjpeg installed, so I wanted
to run a program that uses this library to see if the DWARF is parsed
correctly. Not only is the DWARF not being loaded, the library isn't
being traced at all:

 dima at shorty:~/projects/ltrace$ ldd /usr/bin/geeqie | grep jpeg

         libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fc5cd25e000)

 dima at shorty:~/projects/ltrace$ ./ltrace -l 'libjpeg.so*' /usr/bin/geeqie /tmp/001.jpg

 Could not init LIRC support
 +++ exited (status 0) +++

I know that functions from this library are actually being called (and
the DWARF can be loaded) because gdb breakpoints are hit. I haven't
debugged this thoroughly. Anybody have any obvious ideas in the
meantime?

dima