Potential false positives reported by Dr.Memory within Threading Building Blocks (Intel® TBB) #2004
Comments
|
TBB developers seem to concur that this is a false positive: here is their response in the 01org/tbb repository's issue tracker (x-referenced above): alexey-katranov commented 15 hours ago Please confirm that this is indeed the case (time permitting). |
|
Yes, a custom allocator that pads can result in problems tracking which addresses are addressable. The typical solution is to annotate the allocator so that the tool knows which range of memory it allocated. That feature is not yet present in Dr. Memory (#107). Do your custom allocators already have Valgrind annotations? If so the plan is for Dr. Memory to support those. |
|
Thanks for your response! As the issue is with a third-party library (TBB), i.e. the custom allocators are in their code, I've readdressed your question to them (in this thread). |
|
As far as I know, Valgrind does not raise the discussed issue. Moreover, Intel TBB library does not have any Valgrind annotations at all. You can contribute the required annotations but I cannot promise if they will become a part of the Intel TBB library because it will be the first example and they are not required for Valgrind. |
|
"Assertion !p || prefix().context == p->prefix().context failed on line 797 of file ..........include\tbb\task.h I understand how to suppress results but are there some options to completely ignore TBB custom allocations so that it won't crash with lots of false memory leaks? |
Even when used on a toy example (from https://software.intel.com/en-us/node/506153):
one gets the following report with UNADDRESSABLE ACCESS beyond heap bounds errors:
Here is the log:
This is probably due to nonstandard functions, NFS_Allocate() and NFS_Free() (which do not seem to be among
o A call to malloc (or calloc or realloc, or Windows equivalents HeapAlloc or HeapReAlloc or the Local or Global versions) inside of a heap region
tracked by Dr. Memory),
being used to allocate/free a padded (by task_prefix_reservation_size = sizeof(task_prefix) bytes in front ) data structure, task , in task& generic_scheduler::allocate_task(). As soon as we access the prefix memory (by invoking the task::prefix() method), Dr. Memory complains about unaddressable access (see the stacks above).
I'm having trouble figuring out whether this is a real issue within TBB, or indeed a false positive reported due to current Dr. Memory limitations; in the latter case, it may make sense to suppress them (e.g., by automatically putting them into potential_errors.txt) until Dr. Memory learns to handle these calls correctly.
Your advice will be much appreciated!
-- Aleksey
18C '96
The text was updated successfully, but these errors were encountered: