DynamoRIO / DynamoRIO/drmemory

Per-thread data for live threads at exit occasionally reported as leaked, occurs in winthreads

Open
#683 5 comments 0 reactions 0 assignees View on GitHub
Migrated OpSys-Windows Priority-Medium
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.