Databases
StackOverflow2013
Postsdbo
POmissing symbols in valgrind stacktrace
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POmissing symbols in valgrind stacktrace
    primarykey
    data
    text
    <p>I'm using valgrind to debug a binary which uses loadable libraries via dlopen. On debian stable the stacktrace does not contain symbols for calls inside the loadable lib.</p> <pre><code>| | -&gt;11.55% (114,688B) 0x769492C: ??? | | | -&gt;11.55% (114,688B) 0x7697289: ??? | | | -&gt;11.55% (114,688B) 0x769806F: ??? | | | -&gt;11.55% (114,688B) 0x419812: myfunc (main.c:1010) </code></pre> <p>Valgrind on debian unstable works fine and the symbols are properly resolved. So I started looking what is different. I have these packages on both systems (valgrind was updated to 3.7 from unstable):</p> <pre><code>ii valgrind 1:3.7.0-1+b1 ii libtool 2.2.6b-2 ii gcc 4:4.4.5-1 ii binutils 2.20.1-16 </code></pre> <p>The libs are not stripped and contain debuginfo:</p> <pre><code> ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x33ffd210859178c15bb3923c5491e1a1b6065015, not stripped </code></pre> <p>Looking closer I noticed that the size of the libraries are different, on debian unstable the lib is slightly bigger. Comparing them with readelf, the size of the debug info is bigger.</p> <pre><code> [26] .debug_aranges PROGBITS 0000000000000000 00a74c 000090 00 0 0 1 [27] .debug_pubnames PROGBITS 0000000000000000 00a7dc 000385 00 0 0 1 [28] .debug_info PROGBITS 0000000000000000 00ab61 00512f 00 0 0 1 [29] .debug_abbrev PROGBITS 0000000000000000 00fc90 0006e2 00 0 0 1 [30] .debug_line PROGBITS 0000000000000000 010372 002314 00 0 0 1 [31] .debug_str PROGBITS 0000000000000000 012686 0019d3 01 MS 0 0 1 [32] .debug_loc PROGBITS 0000000000000000 014059 000f24 00 0 0 1 [33] .debug_macinfo PROGBITS 0000000000000000 014f7d 179082 00 0 0 1 [34] .debug_ranges PROGBITS 0000000000000000 18dfff 000060 00 0 0 1 </code></pre> <p>This makes me think that something is missing from the debug info section from the binaries built on debian stable. Now my question is: why and how are the binaries different? The tools (gcc, libtool, binutils) used in the build are the same, including the compiler/linker flags and commands (I checked with diff on make's output).</p> <p><strong>Update:</strong> The debug_info section size difference came from the fact that the full path of the source file is stored there as well and the build home was different. Also there are different openssl versions on unstable/stable which added some different symbols to the debug_info section. Hence the difference in debug_info size.</p> <p>Running valgrind in debug mode (-d -v -v) shows that it reads symbols from the loadable lib in both cases:</p> <pre><code>--19837-- Reading syms from /usr/lib/myplugin.so (0x6c62000) </code></pre>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USb0ti
    1. USb0ti
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POmissing symbols in valgrind stacktrace
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POmissing symbols in valgrind stacktrace
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POmissing symbols in valgrind stacktrace
      1. USziu
      1. VTFavorite
    1. COWhat are the differences in Make's output? Is it possible the binary on stable was partly stripped? I'm not sure what `file` would show in this case, but `strip` has a number of options, including (I believe) the ability to only strip debug info.
      singulars
      1. POmissing symbols in valgrind stacktrace
      1. USDan Fego
    2. COThere was no difference in make's output, except for the base path (different home directories). strip was not called. The debug_* sections are there in both builds, just the sizes differ for some.
      singulars
      1. POmissing symbols in valgrind stacktrace
      1. USb0ti
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload