> 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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
