问题
(This question is related to Filtering out junk from valgrind output).
I'm trying to debug memory leaks in a large project that is mostly out of my hands --- it's a fork of a codebase that's on the order of millions of lines of code, although most of it probably isn't relevant to the small section that I'm working on. Since it would be very tough to look through it by hand, I'm trying to use valgrind to track down the leaks.
The problem is that the stack traces look like this:
==83597== 920 bytes in 1 blocks are possibly lost in loss record 750 of 864
==83597== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==83597== by 0x548EF93: myproject_malloc (mysourcefile.c:48)
==83597== by 0x4F13FD5: ??? (in /path/to/project/library-version.so)
==83597== by 0xFFEFFFD5F: ???
==83597== by 0x38F: ???
==83597== by 0xFFEFFFE5F: ???
==83597== by 0xF: ???
==83597== by 0x54542FF: ??? (in /path/to/project/library-version.so)
==83597== by 0x4F536CA: ??? (in /path/to/project/library-version.so)
==83597== by 0x64B981F: ???
==83597== by 0xF: ???
==83597== by 0x54542FF: ??? (in /path/to/project/library-version.so)
What might be causing the tiny addresses like 0xF, 0x38F, etc? I'm on a Debian-flavored x86_64 Linux distro. I can't find a reference for x86_64 but as far as I can tell, real data shouldn't start until a much higher address.
回答1:
The issue was that a Makefile was turning on fomit-frame-pointer.
来源：https://stackoverflow.com/questions/34346248/what-can-cause-strange-addresses-in-a-valgrind-stack-trace