Skip to content

Add memcheck and asan annotations #275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 7, 2024
Merged

Conversation

igchor
Copy link
Member

@igchor igchor commented Feb 29, 2024

Closes #217

TBB pool is not annotated because tbb keeps metadata inline and hence we cannot mark the memory as undefined/unaccessible on free.

Ref: https://valgrind.org/docs/manual/valgrind_manual.pdf

@igchor igchor requested a review from a team as a code owner February 29, 2024 18:44
@igchor igchor force-pushed the annotations branch 5 times, most recently from 696de5f to 2faf454 Compare February 29, 2024 23:25
@igchor igchor force-pushed the annotations branch 2 times, most recently from 21a6b88 to e3c8d6f Compare March 1, 2024 18:52
@bratpiorka
Copy link
Contributor

@igchor about TBB - why do we can't annotate mem as unaccessible on free()? Even if TBB keeps metadata inline, you pass ptr+size to the Valgrind so you annotate only the portion of memory - internal TBB accesses outside this portion shouldn't cause problems?

@igchor
Copy link
Member Author

igchor commented Mar 4, 2024

@igchor about TBB - why do we can't annotate mem as unaccessible on free()? Even if TBB keeps metadata inline, you pass ptr+size to the Valgrind so you annotate only the portion of memory - internal TBB accesses outside this portion shouldn't cause problems?

TBB seems to store some metadata in the allocation itself (first 8 bytes) after free (similarly as we do in base_alloc - but in base_alloc we know exactly where and how much metadata we store). Which means that if we mark the allocation as inaccessible, it will trigger an error when tbb writes it's metadata.

@bratpiorka
Copy link
Contributor

TBB seems to store some metadata in the allocation itself (first 8 bytes) after free (similarly as we do in base_alloc - but in base_alloc we know exactly where and how much metadata we store). Which means that if we mark the allocation as inaccessible, it will trigger an error when tbb writes it's metadata.

so can we annotate the rest of memory, after these 8 bytes? or this doesn't make sense?

@bratpiorka
Copy link
Contributor

general comment: it is quite complex code - it would be great if you could extend the comments and describe why we do annotations in each case

@bratpiorka bratpiorka requested a review from kswiecicki March 5, 2024 18:08
@bratpiorka
Copy link
Contributor

@kswiecicki we need second approver - could you look at this?

@igchor
Copy link
Member Author

igchor commented Mar 6, 2024

TBB seems to store some metadata in the allocation itself (first 8 bytes) after free (similarly as we do in base_alloc - but in base_alloc we know exactly where and how much metadata we store). Which means that if we mark the allocation as inaccessible, it will trigger an error when tbb writes it's metadata.

so can we annotate the rest of memory, after these 8 bytes? or this doesn't make sense?

We could if we're sure that tbb always uses only 8 bytes. This might be true but I don't know if we want to rely on such behavior.

@bratpiorka bratpiorka merged commit 9097d91 into oneapi-src:main Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add valgrind annotations to base_alloc (and os provider?)
4 participants