DynamoRIO / DynamoRIO/drmemory
Per-thread data for live threads at exit occasionally reported as leaked, occurs in winthreads
- Dominant language
- C
- Stars
- 2.7k
- Forks
- 290
- PR merge metrics
- No merged PRs in 30d
Description
_From [rnk@google.com](https://code.google.com/u/rnk@google.com/) on November 11, 2011 10:02:09_
Splitting from issue #680 since if I'm right this problem has a larger scope.
Sometimes we get the following leak from winthreads on the bot:
Error `#3`: LEAK 532 direct bytes 0x005ce7c0-0x005ce9d4 + 0 indirect bytes
#0 _calloc_impl (0x00ad82e3 )
f:\dd\vctools\crt_bld\self_x86\crt\src\calloc_impl.c:94
#1 _calloc_crt (0x00ad2bfd )
f:\dd\vctools\crt_bld\self_x86\crt\src\crtheap.c:61
#2 _beginthreadex (0x00ad137f )
f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:170
#3 main (0x00ad119e )
e:\b\build\slave\win_7_x64_drm_checkout\drmemory\tests\winthreads.c:86
When I run locally, this allocation is marked as reachable and so it is not reported, but I can verify that it still exists even if I call CloseHandle on the return value of _beginthreadex in the test.
I'm reasonably certain that this 532 byte allocation is a struct _tiddata which holds per-thread data. My theory is that the leak scan is occurring while DR has the app's TEB swapped out, so we're not finding it as a root. At first I was just going to suppress this allocation, but it seems like this struct is likely to reference other memory. If my guess is right, then we need to make sure we consider it a root or we'll non-deterministically report thread-local data as leaked.
_Original issue: http://code.google.com/p/drmemory/issues/detail?id=683_
Contributor guide
Assessment
This issue has not been assessed yet.