Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 40151 Build 40242: arc lint + arc unit
Event Timeline
FWIW for kernel sanitizers we want an ability to memorize few _additional_ stacks per heap object:
https://bugzilla.kernel.org/show_bug.cgi?id=198437
That's very useful for any kind of asynchronous processing environments that involves tasks, callbacks, thread pools, etc (read - almost all large C/C++ software today) because allocation/free stack may be meaningless and/or other stacks may be crucially important.
compiler-rt/include/sanitizer/asan_interface.h | ||
---|---|---|
320 | Add some explanation of when it is going to be successful. |
compiler-rt/include/sanitizer/asan_interface.h | ||
---|---|---|
320 | Racey, as in someone could be deallocating this memory on another thread? |
compiler-rt/include/sanitizer/asan_interface.h | ||
---|---|---|
320 | malloc_usable_size() only reads the data. BTW, the name "asan_update_allocation" doesn't seem to reflect the action. |
Agreed. We don't have space in the chunk header to fit any additional stack traces for free though. And the kernel has its own runtime implementation anyway.
compiler-rt/include/sanitizer/asan_interface.h | ||
---|---|---|
320 | OK, I made the store atomic. It could still race with deallocation, but the same is true for malloc_usable_size. Changed the name to asan_update_allocation_context |
Btw, we can implement this really nicely in MSan with origin tracking.
And if we really wanted, we could pull the chained origin stack depot code to sanitizer_common and use it in asan for the extra stack traces.
But this sounds like a lot of work for a fringe feature.
Add some explanation of when it is going to be successful.
Also, what about threads?
This API is racey