This applies patch by user simonb.
Quoting:
Relocation packing splits a single executable load segment into two. Before:
LOAD 0x000000 0x00000000 0x00000000 0x2034d28 0x2034d28 R E 0x1000
LOAD 0x2035888 0x02036888 0x02036888 0x182d38 0x1a67d0 RW 0x1000
After:
LOAD 0x000000 0x00000000 0x00000000 0x14648 0x14648 R E 0x1000
LOAD 0x014648 0x0020c648 0x0020c648 0x1e286e0 0x1e286e0 R E 0x1000
...
LOAD 0x1e3d888 0x02036888 0x02036888 0x182d38 0x1a67d0 RW 0x1000
The .text section is in the second LOAD, and this is not at
offset/address zero. The result is that this library shows up in
/proc/self/maps as multiple executable entries, for example (note:
this trace is not from the library dissected above, but rather from an
earlier version of it):
73b0c000-73b21000 r-xp 00000000 b3:19 786460 /data/.../libchrome.2160.0.so
73b21000-73d12000 ---p 00000000 00:00 0
73d12000-75a90000 r-xp 00014000 b3:19 786460 /data/.../libchrome.2160.0.so
75a90000-75c0d000 rw-p 01d91000 b3:19 786460 /data/.../libchrome.2160.0.so
When parsing this, pprof needs to merge the two r-xp entries above
into a single entry, otherwise the addresses it prints are incorrect.
The following fix against 2.2.1 was sufficient to make pprof --text
print the correct output. Untested with other pprof options.
When trying to use pprof on my machine, the symbols of my program were
not being recognized.
It turned out that pprof, when calculating the offset of the text list
of mapped objects (the last section of the CPU profile data file), was
assuming that the slot size was always 4 bytes, even on 64-bit machines.
This led to ParseLibraries() reading a lot of garbage data at the
beginning of the map, and consequently the regex was failing to match on
the first line of the real (non-garbage) map.
Copes with ? for line number (converts to 0).
Copes with (discriminator <num>) suffixes to file/linenum (removes).
Change-Id: I96207165e4852c71d3512157864f12d101cdf44a
Quoting from email:
I had the same question as William posted to stack overflow back on
Dec 9,2013: How to display symbols in stack trace of google-perftools
heap profiler (*). I dug into the source and realized the
functionality was not there but could be added. I am hoping that
someone else will find this useful/helpful.
The patch I created will not attach so I am adding below.
Enjoy!
-- Michael
* http://stackoverflow.com/questions/20476918/how-to-display-symbols-in-stack-trace-of-google-perftools-heap-profiler
This applies patch sent by user iamxujian.
Clearly, when I updated debugallocation to fix issue-464 I've broken
no-mmap path by forgetting closing brace.
This patch fixes the SetupAggressiveDecommit initialization to run after
pageheap_ creation. Current code it not enforcing it, since
InitStaticVars is being called outside the static_vars module.
After code for issue 359 was applied PreamblePatcher started using
it's own code to manage memory of stub code fragments. It's not using
new[] anymore. And it automatically frees stub code memory on
Unpatch.
Clearly, author of that code forgot to remote that no more needed
delete call. With that delete call we end up trying to free memory
that was never allocated with any of known allocators and crash.
This patch fixes the stacktrace creating when the function is
interrupted by a signal. For Linux, the vDSO signal trampoline symbol is
compared against LR from stack backchain and handled different in that
case (since the signal trampoline layout a different stack frame).
Because of this extensive change the PowerPC stacktrace code has now
been refactored to split in Linux and Darwin specific codes.
This patch cleans up unused VDSO getcpu racking from VDSOsupport class,
since the code is not used anywhere in gperftools and symbol name is not
architecture independent.
Fixed the wrapper for the syscall sys_clone and the test for heap
checker on PPC64 LE. Both use the ODP structure, which is only
used on BE architectures.
pprof was writing profile data in a way that only works for little-endian
files, this patch verifies if the system is big-endian and writes packed
data correctly.
In systems where addr2line has a version greater than 2.22 pprof fails
in discover the separator symbol (_fini). This patch identifies if
addr2line can find the symbol, otherwise pprof uses objdump to recover
a address that addr2line's newer versions can recognize as the separator
function.
This is port of corresponding chromium change at:
https://codereview.chromium.org/55333002/
Basic idea is that sometimes apps that use tc_set_new_mode in order to
have C++ out-of-memory handler catch OOMs in malloc, need to invoke
usual malloc that returns 0 on OOM.
That new API is exactly for that. It'll always return NULL on OOM even
if tc_new_mode is set to true.
It was reported that pthread_once is expensive, especially on ppc.
In new implementation in hot path instead of doing potentially
expensive atomic read with barrier, we do just plain read.
It's slightly less robust than older implementation, but it should be
faster.
New code is making assumption that programs do not spawn threads
before main() is called. And therefore all variables & modules are
initialized before threads are created. Which looks like pretty safe
assumption. With that assumption, doing plain read is safe, because
current_instance is initialized as part of module init and therefore
before threads are spawned.
This patch is based on feedback of Adhemerval Zanella.
This patch fix the PPC64 guard to get the function address for PPC64v2.
It removes the use of an indirection (to get the ODP text address),
since the PPCv2 does not have function descriptors.
This applies patch by davide.italiano@10gen.com:
heap-checker.h contains the following friend declaration of main:
friend int main(int, char**).
C99 allows another declaration of main, i.e. int main(int, char**,
char**), and if code uses it and includes the heap-checker header,
this might result in a conflict, e.g.
error: declaration of C function 'int main(int, char**, char**)' conflicts with
int main(int argc, char* argv[], char** envp)
Actually the comment above the friend declaration of main() mentions
that this is required to get the unittest working and for other
internal usage, but I'm not completely sure if this is true as long as
I'm able to build and run the unittest removing the declaration.
Caused by premature merging of previous patch.
When we're searching for backtrace in libexecinfo and don't find it,
we should not reset UNWIND_LIBS to empty value.
Correct fix is to first search for backtrace in libunwind and then to
search for it in libexecinfo.
Chrome has code to decommit (release back to OS) every span that's
released. I don't want to make it default, but indeed some
applications may want to enable this mode.
The code itself is taken from 2-way-merging of code from Chromium
fork.
