This CL introduces the stack shadowing mechanism that should help TCMalloc's
heap leak checker to unwind the memory allocation stacks better.
Currently, if a memory region is allocated from a library built without frame
pointers heapchecker is unable to unwind the stack and records only the top
frame. This is inconvenient, because:
-- several leaks from different places are treated as leaks from the same
source
-- it's hard to suppress such leaks, because a one-line suppression is
uninformative
linux_shadow_stacks.cc keeps the threads' IP and SP values in thread-local
stacks upon each function entry/exit using gcc function instrumentation
(-finstrument-functions).
The GetStackTrace routine from stacktrace_shadow-inl.h unwinds the stack as
usual (using frame pointers), but then updates the result with the shadow stack
frames which SP values are below the bottom frame of the unwind result.
Note that -finstrument-functions affects only Chromium code, not the libraries.
This means that we cannot get more than one library function frame at the top
of the stack.
For example, consider a libfoo library that has a public foo_do_something()
routine which allocates memory via foo_alloc(). If Chromium calls
foo_do_something() from ChromeCallFoo(), then the following call chain
effectively happens:
main -> ChromeCallFoo -> foo_do_something -> foo_alloc
If libfoo is built with -fomit-frame-pointers, heapcheck can unwind only the
last stack frame:
foo_alloc
On the other hand, the shadow stack at the allocation site contains everything
below the libfoo calls:
main -> ChromeCallFoo
As a result the following allocation stack is recorded:
main -> ChromeCallFoo -> foo_alloc
This is enough to distinguish between e.g. ChromeCallFoo1 and ChromeCallFoo2
Review URL: http://codereview.chromium.org/3120017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57658 0039d316-1c4b-4281-b951-d872f2087c98
5 files changed
