|
From: Munagala N. <mun...@gm...> - 2018-12-28 09:56:46
|
Hi Team, We are using valgrind tool to find memory leaks from our native process on "LE" target. Our processes has a dlopen() function call to dynamically load the shared libraries. Unfortunately we are not seeing symbol information from this dynamically loaded shared library. While googling for this issue, found below link where they suggested to export "LD_PRELOAD" variable. Even after exporting this one, symbols are not coming correctly. Can you please help with any suggestions on this regard ? Valgrind Version:3.13 -- Regards Naresh Babu 09900139337 |
|
From: John R. <jr...@bi...> - 2018-12-28 15:31:22
|
On 12/28/18 09:56 UTC, Munagala Naresh wrote:
> We are using valgrind tool to find memory leaks from our native process on "LE" target.
> Our processes has a dlopen() function call to dynamically load the shared libraries. Unfortunately we are not seeing symbol information from this dynamically loaded shared library.
>
> While googling for this issue, found below link where they suggested to export "LD_PRELOAD" variable. Even after exporting this one, symbols are not coming correctly.
>
> Can you please help with any suggestions on this regard ?
>
> Valgrind Version:3.13
That last line giving the version of valgrind is the only useful information contained in the query.
What is an example actual complaint from valgrind output that shows a lack of symbol information?
What is the hardware architecture, using some widely-recognized designator [not "LE"]?
What is the operating system, and what version is it? If Linux, then what flavor
(Fedora, Ubuntu, custom, etc.), and what is the output from running "uname -a"?
What is the evidence that the shared library *does* have symbols?
For example on Linux, if the output from "file my_lib.so" contains
"stripped", then my_lib.so does not contain symbols that are useful
to valgrind. If the output from "readelf --sections my_lib.so"
does not show sections named .debug_info, .debug_abbrev, .debug_line,
and .debug_str then that is more evidence of a lack of useful symbols.
Some software build systems put debug symbols into a separate file.
If so, then "readelf --note my_lib.so" will contain "NT_GNU_BUILD_ID"
and "Build ID"; and running
strace -e trace=file -o strace.out valgrind ./my_app
will show system calls similar to
open("/usr/lib/debug/.build-id/e3/64df80b97b7dbd487a7c48b69b618b0a041958.debug", O_RDONLY) = 4
where valgrind looked to find the debuginfo for a Build ID of e364df80b97b7dbd487a7c48b69b618b0a041958.
The valgrind FAQ does have a relevant hint; search for "symbol".
|