Band-aid fix for test hangs:

Band-aid fix for test hangs:

What happens is after I enabled tcmalloc's debugallocation
in http://code.google.com/p/chromium/issues/detail?id=30715
cc_unittests started hanging in StackDumpSignalHandler, triggered
by SIGSEGV triggered by:

@0  0x00000000019c6c85 in tcmalloc::Abort () at third_party/tcmalloc/chromium/src/base/abort.cc:15
@1  0x00000000019b39c1 in LogPrintf (severity=-4, 
    pat=0x32aeb18 "memory allocation/deallocation mismatch at %p: allocated with %s being deallocated with %s", ap=0x7fff52c379e8)
    at third_party/tcmalloc/chromium/src/base/logging.h:210
@2  0x00000000019b3a8b in RAW_LOG (lvl=-4, 
    pat=0x32aeb18 "memory allocation/deallocation mismatch at %p: allocated with %s being deallocated with %s")
    at third_party/tcmalloc/chromium/src/base/logging.h:230
@3  0x00000000019c3fb1 in MallocBlock::CheckLocked (this=0x7fd18f143400, type=-21308287)
    at ./third_party/tcmalloc/chromium/src/debugallocation.cc:461
@4  0x00000000019c3c42 in MallocBlock::CheckAndClear (this=0x7fd18f143400, type=-21308287)
    at ./third_party/tcmalloc/chromium/src/debugallocation.cc:401
@5  0x00000000019c436a in MallocBlock::Deallocate (this=0x7fd18f143400, type=-21308287)
    at ./third_party/tcmalloc/chromium/src/debugallocation.cc:557
@6  0x00000000019c1929 in DebugDeallocate (ptr=0x7fd18f143420, type=-21308287)
    at ./third_party/tcmalloc/chromium/src/debugallocation.cc:998
@7  0x00000000028d1482 in tc_delete (p=0x7fd18f143420) at ./third_party/tcmalloc/chromium/src/debugallocation.cc:1232
@8  0x000000000097dc04 in cc::ResourceProvider::deleteResourceInternal (this=0x7fd191827da0, it=...) at cc/resource_provider.cc:242
@9  0x000000000097daaf in cc::ResourceProvider::deleteResource (this=0x7fd191827da0, id=1) at cc/resource_provider.cc:230
@10 0x00000000006f9824 in (anonymous namespace)::ResourceProviderTest_Basic_Test::TestBody (this=0x7fd18dc5abf0)
    at cc/resource_provider_unittest.cc:328
@11 0x00000000008ec801 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x7fd18dc5abf0, 
    method=&virtual testing::Test::TestBody(), location=0x29463ab "the test body") at testing/gtest/src/gtest.cc:2071
@12 0x00000000008e9665 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x7fd18dc5abf0, 
    method=&virtual testing::Test::TestBody(), location=0x29463ab "the test body") at testing/gtest/src/gtest.cc:2123
@13 0x00000000008dee0d in testing::Test::Run (this=0x7fd18dc5abf0) at testing/gtest/src/gtest.cc:2143
@14 0x00000000008df3ea in testing::TestInfo::Run (this=0x7fd191823020) at testing/gtest/src/gtest.cc:2319
@15 0x00000000008df8dc in testing::TestCase::Run (this=0x7fd19181f0d0) at testing/gtest/src/gtest.cc:2426
@16 0x00000000008e3eea in testing::internal::UnitTestImpl::RunAllTests (this=0x7fd19829dd60) at testing/gtest/src/gtest.cc:4249

The hang is triggered by calling backtrace() in the signal handler.

The problem reported by tcmalloc is "memory allocation/deallocation mismatch at 0xa3af520: allocated with new [] being deallocated with delete".

BUG=30715, 101155
TEST=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=165067

[Scott Hess - ex-Googler, 2012-10-30 23:47:59]

https://codereview.chromium.org/11340054/diff/1002/base/process_util_posix.cc
File base/process_util_posix.cc (right):

https://codereview.chromium.org/11340054/diff/1002/base/process_util_posix.cc...
base/process_util_posix.cc:158: #if defined(OS_MACOSX)
I would prefer to have the PrintBacktrace() enabled on OSX, since it doesn't use
tcmalloc anyhow.

I agree that we should be using backtrace_symbols_fd() or whatever it is.  But
that will lose out on demangling on Linux, I think.

[Paweł Hajdan Jr., 2012-10-30 23:57:21]

PTAL

Now simply disabling troublesome code on non-Mac. I should have a fix (and
re-enable this) this week.

I think the gain from debugallocation being on outweighs loss of in-process
stack dumping for a while.

[Scott Hess - ex-Googler, 2012-10-30 23:59:55]

lgtm

https://codereview.chromium.org/11340054/diff/7001/base/process_util_posix.cc
File base/process_util_posix.cc (right):

https://codereview.chromium.org/11340054/diff/7001/base/process_util_posix.cc...
base/process_util_posix.cc:145: // TODO(phajdan.jr): Fix hangs caused by using
malloc below.
Ref a tracking bug for this, and maybe s/malloc/tcmalloc/.

[jar (doing other things), 2012-10-31 00:00:28]

Patch set 3 LGTM (especially since shess likes it!)

[Alexander Potapenko, 2012-11-01 07:39:41]

On 2012/10/31 00:00:28, jar wrote:
> Patch set 3 LGTM (especially since shess likes it!)

I suggest to add some USE_DEBUGALLOCATION macro (if we don't have it yet) and
check for it instead.
It's really messy to allocate and deallocate memory in the signal handler, but
backtraces are extremely helpful on Linux, so it's better to keep them for
non-debugallocation builds

[Scott Hess - ex-Googler, 2012-11-01 16:58:43]

On 2012/11/01 07:39:41, Alexander Potapenko wrote:
> On 2012/10/31 00:00:28, jar wrote:
> > Patch set 3 LGTM (especially since shess likes it!)
> 
> I suggest to add some USE_DEBUGALLOCATION macro (if we don't have it yet) and
> check for it instead.
> It's really messy to allocate and deallocate memory in the signal handler, but
> backtraces are extremely helpful on Linux, so it's better to keep them for
> non-debugallocation builds

I think that if we wanted to be safer, it would make sense to use a static
buffer for backtrace(), and backtrace_symbols_fd() instead of all of the
demangling stuff.  AFAICT, the glibc implementation of backtrace_symbols_fd() is
all stack-based memory usage and system calls.

[Paweł Hajdan Jr., 2012-11-01 18:04:35]

So, some update for you (thank you for feedback):

1. This is not just for debugallocation. The signal handler is not async-signal
safe, and may hang even without debugallocation.

2. I have a fix locally, and I'm now working on getting it reviewed and
committed. Fun thing is that backtrace() itself can use malloc the first time
it's called. I've solved that by warming it up before enabling our signal
handler.