Re: [Libunwind-devel] Crash in libunwind 0.99 on x86_64

[Dave Wright]

> libunwind is reliable only as long as the compiler generated unwind
> information is reliable.
> Not all addresses go through msync() based validation. Enabling validation
> on every dereference has a pretty big performance cost to tcmalloc.
> Debugging the problem normally requires figuring out which one of the 42
> frames libunwind was unwinding when it accessed the bad address
> (UNW_DEBUG_LEVEL=x) and examining what went wrong.
> I would suggest testing with the git version to see if the problem is
> resolved. Another alternative is to stub out GetStackTrace() (as in { return
> 0; }) from tcmalloc if you don't care about sampled allocations.

Thanks Arun. I suspect the git version would fix the crash I saw, if
it occurred at the exact same address in the first page again, however
I wanted to understand the likelihood of getting a crash at some other
place in the future.
To be clear, this isn't something that is apparently common or easily
reproducible - I estimate my program (which is undergoing stress
testing) had done over 10 billion allocations over several hours at
the time the crash occurred.
 I haven't seen it again several hours (and several billion more
allocations) since.
That being said, if there's any chance of it recurring, I need to prevent it.

It looks like stack sampling can be disabled by setting:
FLAGS_tcmalloc_sample_parameter  (--tcmalloc_sample_parameter) to 0.
Is there anything important lost by doing this? That flag isn't
mentioned in the documentation anywhere.

-Dave Wright