From [email protected] on August 23, 2010 08:38:33

This doesn't happen on base_unittests but happens on googletest tests.

svn checkout -r 375 http://googletest.googlecode.com/svn/trunk/ googletest
cd googletest\msvc
devenv gtest.sln /Upgrade
devenv gtest.sln /Build "Debug" /Project gtest_unittest

drmemory.exe -- gtest\Debug\gtest_unittest.exe --gtest_filter="InitGoogleTestTest.*"

This has been reproduced with r38 / r414 on Win XP.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=32

From [email protected] on August 26, 2010 09:56:56

base_unittests.exe from issue #251 running on xpsp3 hits an assert:

[----------] 4 tests from WMIUtilTest
[ RUN ] WMIUtilTest.TestLocalConnectionSecurityBlanket
:::Dr.Memory::: ASSERT FAILURE (thread 134248): E:/derek/dr/win32/oss-clients/drmemory/drmemory/readwrite.c:2564: addr + sz > addr (address overflow)

size from a PORT_MESSAGE is -1:

0:001> dt -b pm
Local var @ 0x24529dd4 Type _PORT_MESSAGE
+0x000 u1 :
+0x000 s1 :
+0x000 DataLength : -1
+0x002 TotalLength : -1
+0x000 Length : 0xffffffff
+0x004 u2 :
+0x000 s2 :
+0x000 Type : 0
+0x002 DataInfoOffset : 0
+0x000 ZeroInit : 0
+0x008 ClientId :
+0x000 UniqueProcess : 0x00040023
+0x004 UniqueThread : 0x000a01ca
+0x008 DoNotUseThisField : 1.3916430357687966e-308
+0x010 MessageId : 0xfe
+0x014 u3 :
+0x000 ClientViewSize : 0x1c9048
+0x000 CallbackId : 0x1c9048

Original issue: http://code.google.com/p/drmemory/issues/detail?id=35

From [email protected] on September 02, 2010 05:28:48

Reproducer -> app_unittests
(zip file is 13Mb, I'll send it to you via e-mail)

--gtest_filter="SQL*" passes in ~100ms when run natively but
takes 20+ minutes under Dr. Memory if passes at all (I didn't wait long enough)
and fills the global log file with a huge number of "WARNING: unknown region 0x00030000-0x0013000 marking as defined" lines (approx 1MB/sec)

Original issue: http://code.google.com/p/drmemory/issues/detail?id=44

From [email protected] on August 13, 2010 11:08:52

r33 and v1.2.1 ( r36 ) give 3 uninit reports on the following test:

#include
#include <stdio.h>

template
const char *GetTypeName() {
return typeid(T).name();
}

int main() {
printf("GetTypeName() = "%s"\n", GetTypeName());
return 0;
}

(Build with "cl /Zi test.cpp")

Original issue: http://code.google.com/p/drmemory/issues/detail?id=27

From [email protected] on September 03, 2010 11:24:12

as of r42 , the following code gives false uninit reports:
===test.cpp===
#include <windows.h>

#include <assert.h>
#include <stdio.h>
#include <winuser.h>
#pragma comment(lib, "user32.lib")

#include

void WriteStringToClipboard(const std::string& str) {
HWND hWnd = ::GetDesktopWindow();
assert(::OpenClipboard(hWnd));
::EmptyClipboard();
HGLOBAL data = ::GlobalAlloc(2 /GMEM_MOVABLE/, str.size() + 1);
assert(data != NULL);

char* raw_data = (char*)::GlobalLock(data);
memcpy(raw_data, str.data(), str.size() * sizeof(char));
raw_data[str.size()] = '\0';
::GlobalUnlock(data);

assert(::SetClipboardData(CF_TEXT, data));
::CloseClipboard();
}

void ReadAsciiStringFromClipboard(std::string *result) {
assert(result != NULL);

HWND hWnd = ::GetDesktopWindow();
assert(::OpenClipboard(hWnd));

HANDLE data = ::GetClipboardData(CF_TEXT);
assert(data != NULL);

result->assign((const char*)::GlobalLock(data));

::GlobalUnlock(data);
::CloseClipboard();
}

int main() {
std::string tmp, str = "ASCII";
WriteStringToClipboard(str);
ReadAsciiStringFromClipboard(&tmp);
assert(strcmp(tmp.c_str(), "ASCII") == 0);
return 0;
}

cl /EHsc /Zi /nologo test.cpp
drmemory.exe test.exe

The first stack is: Error `#1`: UNINITIALIZED READ: reading register edx @0:00:01.640 in thread 3428 0x100df1f0 drmemorylib.dll!replace_strlen z:\drmemory\git_svn\drmemory\replace.c:211 0x0040157c test.exe!std::char_traits::length c:\program files\microsoft visual studio 8\vc\include\iosfwd:442 0x00401550 test.exe!std::basic_string,std::allocator >::assign c:\program files\microsoft visual studio 8\vc\include\xstring:1070 0x00401313 test.exe!ReadAsciiStringFromClipboard z:\dr-sandbox\issues\clipboard\test.cpp:35 0x0040138d test.exe!main z:\dr-sandbox\issues\clipboard\test.cpp:44

and the following look related.

Attachment: 45.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=45

From [email protected] on June 09, 2010 07:30:27

Issue 309 : fix wrong assertion in suppression matcher

stats: 56 diff lines

Original issue: http://code.google.com/p/drmemory/issues/detail?id=2

From [email protected] on August 18, 2010 16:30:21

this is in the middle of my issue #26 fix, so operator delete was raising unaddr errors, but this could happen w/ any C++ app or other app w/ very long symbol names:

% bin/drmemory.exe -dr e:/derek/dr/win32/exports -dr_debug -batch -- e:/derek/ issue251 /base_unittests.exe --gtest_filter="*.NewFile"

ChildEBP RetAddr

00 228c8a28 1523ccfc ntdll!ZwRaiseHardError+0x12
01 228c8a78 1520eef4 dynamorio!nt_messagebox+0xec [e:\derek\dr\win32\opensource\core\win32\ntdll.c @ 3205]
02 228c8a8c 150dd5b8 dynamorio!debugbox+0x54 [e:\derek\dr\win32\opensource\core\win32\os.c @ 3434]
03 228c8da8 150dd965 dynamorio!notify+0x1d8 [e:\derek\dr\win32\opensource\core\utils.c @ 1852]
04 228c8e14 150dc9a1 dynamorio!report_dynamorio_problem+0x355 [e:\derek\dr\win32\opensource\core\utils.c @ 2066]
05 228c9140 151fd4db dynamorio!do_file_write+0xb1 [e:\derek\dr\win32\opensource\core\utils.c @ 1648]
06 228c9158 100b0e9c dynamorio!dr_fprintf+0x1b [e:\derek\dr\win32\opensource\core\x86\instrument.c @ 2884]
07 228c9258 100b029a drmemorylib!write_suppress_pattern+0xbac [e:\derek\dr\win32\oss-clients\drmemory\drmemory\report.c @ 439]
08 228c9378 100abbbf drmemorylib!on_suppression_list+0x145a [e:\derek\dr\win32\oss-clients\drmemory\drmemory\report.c @ 563]
09 228c95c0 100ab418 drmemorylib!report_error+0x79f [e:\derek\dr\win32\oss-clients\drmemory\drmemory\report.c @ 1132]
0a 228c95ec 1001bfc3 drmemorylib!report_unaddressable_access+0x28 [e:\derek\dr\win32\oss-clients\drmemory\drmemory\report.c @ 1235]
0b 228c9878 10018a9c drmemorylib!handle_mem_ref+0x31c3 [e:\derek\dr\win32\oss-clients\drmemory\drmemory\readwrite.c @ 2769]
0c 228c99d0 1000ecb1 drmemorylib!check_mem_opnd+0x184c [e:\derek\dr\win32\oss-clients\drmemory\drmemory\readwrite.c @ 2536]
0d 228c9f44 2296008f drmemorylib!slow_path+0x1f41 [e:\derek\dr\win32\oss-clients\drmemory\drmemory\readwrite.c @ 1699]
WARNING: Frame IP not in any known module. Following frames may be wrong.
0e 0012fce0 0042e507 0x2296008f
0f 0012fcf0 0042e00b base_unittests!std::allocator<wchar_t>::deallocate+0x17 [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xmemory @ 140]
10 0012fd08 0042dcca base_unittests!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy+0x6b [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xstring @ 2158]
11 0012fd1c 004fd5d9 base_unittests!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >+0x1a [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xstring @ 907]
12 0012fd28 004fd5a9 base_unittests!std::pairstd::basic_string<char,std::char_traits<char,std::allocator > const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >::pairstd::basic_string<char,std::char_traits<char,std::allocator > const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >+0x19
13 0012fd34 004fd516 base_unittests!std::_Tree_nodstd::_Tmap_traits<std::basic_string<char,std::char_traits<char,std::allocator >,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::lessstd::basic_string<char,std::char_traits<char,std::allocator > >,std::allocatorstd::pair<std::basic_string<char,std::char_traits<char,std::allocator > const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,0> >::_Node::_Node+0x19
0:000> .frame 5
05 228c9140 151fd4db dynamorio!do_file_write+0xb1 [e:\derek\dr\win32\opensource\core\utils.c @ 1648]
0:000> dv
f = 0x00000344
fmt = 0x10149dac "%.*s???"
ap = 0x228c9168 "c???"
size = 0xffffffff
logbuf = char [768] "base_unittests.exe!std::_Treestd::_Tmap_traits<std::basic_string<char,std::char_traits<char,std::allocator >,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::lessstd::basic_string<char,std::char_traits<char,std::allocator > >,std::allocatorstd::pair<std::basic_string<char,std::char_traits<char,std::allocator > const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,0> >::_Treestd::_Tmap_traits<std::basic_string<char,std::char_traits<char,std::allocator >,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::lessstd::basic_string<char,std::char_traits<char,std::allocator > >,std::allocator<std::pair<std::basic_string<char,s"

Original issue: http://code.google.com/p/drmemory/issues/detail?id=29

From [email protected] on September 07, 2010 09:21:52

On Windows, as of r46 :
===test.cpp===
#include <windows.h>

DWORD WINAPI foo(void_) {
// See http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx #pragma pack(push,8)
typedef struct tagTHREADNAME_INFO
{
DWORD dwType; // Must be 0x1000.
LPCSTR szName; // Pointer to name (in user addr space).
DWORD dwThreadID; // Thread ID (-1=caller thread).
DWORD dwFlags; // Reserved for future use, must be zero.
} THREADNAME_INFO;
#pragma pack(pop)
THREADNAME_INFO info = { 0x1000, "My Thread Name", GetCurrentThreadId(), 0};
_try {
RaiseException(0x406D1388, 0, sizeof(info)/sizeof(DWORD), (DWORD)&info );
}
__except(EXCEPTION_CONTINUE_EXECUTION) { }
return 0;
}

int main() {
DWORD id = 0;l
HANDLE thr = CreateThread(NULL, 0, foo, NULL, 0, &id);
WaitForSingleObject(thr, INFINITE);
return 0;
}

cl /Zi /nologo && drmemory.exe test.exe
->
Error #1: UNINITIALIZED READ: reading 0x008cfc44-0x008cfc48 4 byte(s) within 0x008cfc44-0x008cfc48
@0:00:01.641 in thread 4256
system call NtContinue

0x0040108b <test.exe+0x108b> test.exe!foo
z:\dr-sandbox\issues\threadname\test.cpp:16
0x7c80b729 <KERNEL32.dll+0xb729> KERNEL32.dll!GetModuleFileNameA
??:0

Original issue: http://code.google.com/p/drmemory/issues/detail?id=48

From [email protected] on August 22, 2010 19:36:17

it's b/c operator delete (debug version only, and delete only: debug
version of oprator new does not) grabs the same heap lock as free (so
similar to issue #26 problem where operator delete is ignoring abstraction
barrier of malloc layer):

base_unittests!operator delete+0x3d [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp @ 45]:
45 0074a2dd 6a04 push 0x4
45 0074a2df e88c060200 call base_unittests!_lock (0076a970)

malloc/free:
_mlock(_HEAP_LOCK);
#define _mlock(l) _lock(l)
#define _HEAP_LOCK 4 /* lock for heap allocator routines */

now that all mallocs are stored in a hashtable, unless this is pre-us, if
no size in redzone (which is the case for dbgcrt due to issue #26) should use
hashtable preferentially.

2 Id: 18f7c.153cc Suspend: 1 Teb: 7efd7000 Unfrozen
ChildEBP RetAddr Args to Child
22659b90 7d62884f 000002c4 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
22659bcc 7d62889f 00000000 00000004 00000001 ntdll!RtlpWaitOnCriticalSection+0x19c
22659bec 0076a9ad 00a51dc8 22659c38 00762bc2 ntdll!RtlEnterCriticalSection+0xa8
22659bf8 00762bc2 00000004 56ab68b0 0628fba0 base_unittests!_lock+0x3d [f:\dd\vctools\crt_bld\self_x86\crt\src\mlock.c @ 349]
22659c38 00762ab0 05b2ce80 00000001 22659ca4 base_unittests!_msize_dbg+0x102 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1503]
22659c48 1007ce76 05b2ce80 000002a8 21351414 base_unittests!_msize+0x10 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1459]
22659ca4 1007c40e 00000000 05b2ce80 22659ee0 drmemorylib!get_alloc_size+0x4b6 [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 665]
22659d90 1007b59c 22595ec0 22659e38 00000000 drmemorylib!handle_free_pre+0x96e [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 2079]
22659f08 10085aff 00426587 0074a420 00000000 drmemorylib!handle_alloc_pre_ex+0x9ec [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 3018]
22659f3c 21e13d76 00426587 0074a420 00000000 drmemorylib!handle_alloc_pre+0x22f [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 3102]

0:002> dt RTL_CRITICAL_SECTION 00a51dc8
+0x000 DebugInfo : 0x0023b890
+0x004 LockCount : -22
+0x008 RecursionCount : 1
+0x00c OwningThread : 0x00018e64
+0x010 LockSemaphore : 0x000002c4
+0x014 SpinCount : 0xfa0

ChildEBP RetAddr

00 22529c34 7108edc2 ntdll!ZwWaitForSingleObject+0x15
01 22529c44 710809b3 dynamorio!nt_wait_event_with_timeout+0x12 [e:\derek\dr\win32\opensource\core\win32\ntdll.c @ 3268]
02 22529c68 71080b83 dynamorio!os_wait_event+0x393 [e:\derek\dr\win32\opensource\core\win32\os.c @ 6341]
03 22529c84 710385e8 dynamorio!mutex_wait_contended_lock+0x53 [e:\derek\dr\win32\opensource\core\win32\os.c @ 6371]
04 22529c94 71079a13 dynamorio!mutex_lock+0x58 [e:\derek\dr\win32\opensource\core\utils.c @ 867]
05 22529ca0 10074ad6 dynamorio!dr_mutex_lock+0x33 [e:\derek\dr\win32\opensource\core\x86\instrument.c @ 2367]
06 22529cb0 1007be13 drmemorylib!malloc_lock+0x16 [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 1110]
07 22529d90 1007b59c drmemorylib!handle_free_pre+0x373 [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 2035]
08 22529f08 10085aff drmemorylib!handle_alloc_pre_ex+0x9ec [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 3018]
09 22529f3c 21902595 drmemorylib!handle_alloc_pre+0x22f [e:\derek\dr\win32\oss-clients\drmemory\common\alloc.c @ 3102]
WARNING: Frame IP not in any known module. Following frames may be wrong.
0a 0618f97c 00422fa7 0x21902595
0b 0618f98c 00423548 base_unittests!std::allocator::deallocate+0x17 [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xmemory @ 140]
0c 0618f9a4 00421a1f base_unittests!std::basic_stringbuf<char,std::char_traits,std::allocator >::_Tidy+0x68 [c:\program files (x86)\microsoft visual studio 9.0\vc\include\sstream @ 305]
0d 0618f9b0 0044a5ad base_unittests!std::basic_stringbuf<char,std::char_traits,std::allocator >::~basic_stringbuf<char,std::char_traits,std::allocator >+0x1f [c:\program files (x86)\microsoft visual studio 9.0\vc\include\sstream @ 44]
0e 0618f9bc 0044a559 base_unittests!std::basic_ostringstream<char,std::char_traits,std::allocator >::~basic_ostringstream<char,std::char_traits,std::allocator >+0x2d [c:\program files (x86)\microsoft visual studio 9.0\vc\include\sstream @ 432]
0f 0618f9c8 0069df8c base_unittests!std::basic_ostringstream<char,std::char_traits,std::allocator >::`vbase destructor'+0x19
10 0618fba0 00440650 base_unittests!logging::LogMessage::~LogMessage+0x3dc [c:\users\timurrrr\desktop\chromium\src\base\logging.cc @ 598]
...

Original issue: http://code.google.com/p/drmemory/issues/detail?id=30

From [email protected] on June 11, 2010 11:08:02

$ ctest -S tests\runsuite.cmake
Error(s) when configuring the project
There was an error: The system cannot find the file specified
Error(s) when building project
No tests were found!!!
Error executing SCP: The system cannot find the file specified
Error executing SCP: The system cannot find the file specified
Error executing SCP: The system cannot find the file specified
Problems when submitting via SCP

looks like
find_program(CTEST_SCP_COMMAND cp DOC "copy command for local copy of results")
is not working on Windows.

Changing the line to
"find_program(CTEST_SCP_COMMAND copy DOC "copy command for local copy of results")"
doesn't help

Original issue: http://code.google.com/p/drmemory/issues/detail?id=5

From [email protected] on August 30, 2010 10:23:38

This has appeared in r41 on base_unittests/FileUtilTest tests: http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows&#37;20Tests&#37;20(DrMemory)/builds/2387/steps/memory&#37;20test:&#37;20base_1/logs/stdio [----------] 21 tests from FileUtilTest
[ RUN ] FileUtilTest.GetFilenameFromPath
06:36:46 common.py [INFO] process ended, did not time out

I'll try to create a small reproducer

Original issue: http://code.google.com/p/drmemory/issues/detail?id=42

From [email protected] on August 29, 2010 17:03:33

after my recent multi-heap-set changes cygwin apps hit:

ASSERT is_entirely_in_heap_region()

that's expected since drmem is now intercepting cygwin malloc routines.
however when I add in cygwin heap region tracking I hit unaddrs on cygwin routines touching un-allocated heap, and I don't have cygwin symbols: it seems the cygwin folks don't make any debug info avail for their binary distributions.

for now I'm retracting the Cygwin package until this is all fixed up

Original issue: http://code.google.com/p/drmemory/issues/detail?id=38

From [email protected] on August 22, 2010 19:39:32

---

Microsoft Visual C++ Debug Library

Debug Assertion Failed!

Program: e:\derek\ issue251 \base_unittests.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
Line: 1317

Expression: _CrtIsValidHeapPointer(pUserData)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

Abort Retry Ignore

at first I thought it was b/c app_fls_data == priv_fls_data: which is a
bug, so I fixed that (coming from NtContinue path not setting to priv so
got off on next fcache entrance).

0:000> dd 05b39ba0-20
05b39b80 05b39930 05b02840 009cfe98 0000024c
05b39b90 00000214 00000002 00004d9b fdfdfdfd
05b39ba0 000171e4 ffffffff 00000000 00000000
05b39bb0 00000000 00000001 00000000 00000000
05b39bc0 00000000 00000000 00000000 00000000
05b39bd0 00000000 00000000 00000000 00000000
05b39be0 00000000 00000000 00000000 00000000
05b39bf0 00000000 00000000 00000000 009d1960
0:000> ~1s
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=061855d4 edi=06185570
eip=1ea01ec7 esp=061855a8 ebp=061855d8 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
1ea01ec7 a39cd3831d mov [1d83d39c],eax ds:002b:1d83d39c=0000100c
0:001> kn 30

ChildEBP RetAddr

WARNING: Frame IP not in any known module. Following frames may be wrong.
00 061855a4 7d957469 0x1ea01ec7
01 061855d8 7d957615 USER32!DialogBox2+0x20b
02 06185604 7d95c23f USER32!InternalDialogBox+0xdc
03 061858c8 7d95bafb USER32!SoftModalMessageBox+0x972
04 06185a20 7d999609 USER32!MessageBoxWorker+0x26c
05 06185a80 7d982982 USER32!MessageBoxTimeoutW+0x4d
06 06185aa0 7d9996d2 USER32!MessageBoxExW+0x1b
07 06185abc 0076c896 USER32!MessageBoxW+0x18
08 06185b10 0074b13c base_unittests!__crtMessageBoxW+0x216 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtmbox.c @ 158]
09 06187d7c 0076c630 base_unittests!__crtMessageWindowW+0x3bc [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 363]
0a 0618fe1c 0074ad72 base_unittests!_VCrtDbgReportW+0x8e0 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrptt.c @ 670]
0b 0618fe3c 0074ad3b base_unittests!_CrtDbgReportWV+0x22 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 241]
0c 0618fe64 007626f9 base_unittests!_CrtDbgReportW+0x2b [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 258]
0d 0618fe84 00762590 base_unittests!_free_dbg_nolock+0x139 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1317]
0e 0618febc 0076a35b base_unittests!_free_dbg+0x50 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1258]
0f 0618ff00 7d64abd9 base_unittests!_freefls+0x1eb [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 737]
10 0618ffa8 7d4e069c ntdll!LdrShutdownThread+0x205
11 0618ffb8 7d4e001c kernel32!ExitThread+0x2f
12 0618ffec 00000000 kernel32!BaseThreadStart+0x39
0:001> dt _CrtMemBlockHeader 05b39ba0-20
+0x000 pBlockHeaderNext : 0x05b39930
+0x004 pBlockHeaderPrev : 0x05b02840
+0x008 szFileName : 0x009cfe98 "f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c"
+0x00c nLine : 588
+0x010 nDataSize : 0x214
+0x014 nBlockUse : 2
+0x018 lRequest : 19867
+0x01c gap : [4] "???"

in event_basic_block(tag=0x0076a350)
found call to _free_dbg @0x0076a356 tgt 0x00762540
entering alloc routine 0x00762540 _free_dbg direct pre-retaddr

Error #2: INVALID HEAP ARGUMENT: _free_dbg 0x05b70310
@0:01:57.657 in thread 127200
0x0076a356 <base_unittests.exe+0x36a356> base_unittests.exe!_freefls
f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:737
0x7d64abd9 <ntdll.dll+0x4abd9> ntdll.dll!RtlValidateHeap
??:0
0x7d4e069c <KERNEL32.dll+0x2069c> KERNEL32.dll!ExitThread
??:0
0x7d4e001d <KERNEL32.dll+0x2001d> KERNEL32.dll!FlsSetValue
??:0

prior mallocs:
RtlAllocateHeap-post 0x05b700a0-0x05b702d8 = 0x238 (really 0x05b70098-0x05b702e0 0x248)
RtlAllocateHeap-post 0x05b702f0-0x05b70528 = 0x238 (really 0x05b702e8-0x05b70530 0x248)

so the attempted free via _free_dbg is in the middle of Rtl-allocated mem:
yet the dbg header does line up nicely, yet fails the assert.

also:
+0x0cc app_fls_data : 0x00242540
+0x0d0 priv_fls_data : 0x00242540
though in debug build not hitting any fls assert and still hit app assert

the memory sure looks correct:
0:001> dt _tiddata 05b701e0
+0x000 _tid : 0x18660
...
+0x1f8 _encode_ptr : 0x7d627dd1
+0x1fc _decode_ptr : 0x7d627dc6
0:001> U 7d627dd1 L1
ntdll!RtlEncodePointer:
7d627dd1 8bff mov edi,edi

0:001> dt -v _tiddata
struct _tiddata, 47 elements, 0x214 bytes
== 0n532 bytes

the only 0x214 or 532:
_calloc_dbg-post 0x02b61ec0-0x02b620d4 = 0x214 (really 0x02b61ec0-0x02b620d4 0x214)
@@@ unique callstack #6
0x00769e5a <base_unittests.exe+0x369e5a> base_unittests.exe!_mtinit
f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:395
0x00754d21 <base_unittests.exe+0x354d21> base_unittests.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:215
0x00754caf <base_unittests.exe+0x354caf> base_unittests.exe!mainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:181

+0x0cc app_fls_data : 0x00242520
+0x0d0 priv_fls_data : 0x00242520

identical, but neither is DR memory:
0:001> ?? heapmgt->vmheap
struct vm_heap_t
+0x000 start_addr : 0x25230000 ""
+0x004 end_addr : 0x2d230000 ""

though LdrShutdownThread does get the address from fs:fb4 + offs, and
here's our addr a few entries into FlsData (is it an array?):
0:001> dd 00242520
00242520 002428e8 0023af40 00000000 00000000
00242530 04b222e8 05b701e0 00000000 00000000

the thing was allocated here (separate run):

dispatch: target = 0x0076a0e3
Fragment 27734, tag 0x0076a0e3, flags 0x1000030, shared, size 219:
[base_unittests.exe]
app fls: 0x002428e0 0x0023af40 0x00000000 0x02362e38 0x00000000 0x00000000
Entry into F27734(0x0076a0e3).0x1ae1474b (shared)
Exit from sourceless ibl: bb ret [](target 0x0076a0e8 not in cache)
app fls: 0x002428e0 0x0023af40 0x00000000 0x02362e38 0x00000000 0x05b6f078

0:001> U 0076a0e3
base_unittests!_getptd_noexit+0x63 [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 593]:
0076a0e3 83c404 add esp,0x4
0076a0e6 ffd0 call eax
0076a0e8 85c0 test eax,eax

base_unittests!_getptd_noexit+0x27 [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 588]:
588 0076a0a7 6a00 push 0x0
588 0076a0a9 684c020000 push 0x24c
588 0076a0ae 6898fe9c00 push 0x9cfe98
588 0076a0b3 6a02 push 0x2
588 0076a0b5 6814020000 push 0x214
588 0076a0ba 6a01 push 0x1
588 0076a0bc e81f7affff call base_unittests!_calloc_dbg_impl (00761ae0)
588 0076a0c1 83c418 add esp,0x18
588 0076a0c4 8945f8 mov [ebp-0x8],eax
588 0076a0c7 837df800 cmp dword ptr [ebp-0x8],0x0
588 0076a0cb 7459 jz base_unittests!_getptd_noexit+0xa6 (0076a126)

base_unittests!_getptd_noexit+0x4d [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 593]:
593 0076a0cd 8b4df8 mov ecx,[ebp-0x8]
593 0076a0d0 51 push ecx
593 0076a0d1 8b15b04ea400 mov edx,[base_unittests!__flsindex (00a44eb0)]
593 0076a0d7 52 push edx
593 0076a0d8 a16c1da500 mov eax,[base_unittests!gpFlsSetValue (00a51d6c)]
593 0076a0dd 50 push eax
593 0076a0de e86dfaffff call base_unittests!_decode_pointer (00769b50)
593 0076a0e3 83c404 add esp,0x4
593 0076a0e6 ffd0 call eax
593 0076a0e8 85c0 test eax,eax

_calloc_dbg_impl
_nh_malloc_dbg_impl
_heap_alloc_dbg_impl
_heap_alloc_base

apparently _impl and _base routines are directly called...ugh

Original issue: http://code.google.com/p/drmemory/issues/detail?id=31

From [email protected] on August 04, 2010 11:51:07

I've found this assert running Chromium base_unittests with the following suppression file:

UNINITIALIZED READ
system call NtRaiseException
KERNEL32.dll!RaiseException
*!DebuggerProbe
*!DebuggerKnownHandle

Attached are the dumpcore, results and global.XYZ.txt files.
[multipart .zip containing .7z]

This has been introduced by r25 - r27

Original issue: http://code.google.com/p/drmemory/issues/detail?id=20

From [email protected] on August 30, 2010 09:52:32

This happens when the last line of a suppression file is not empty.
Example suppression is attached.

Attachment: suppress.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=41

From [email protected] on August 31, 2010 11:52:50

We should make the Cygwin build also support mingw which should be a subset: it should just work, so this issue is mainly about testing and documenting.

Long-term the plan is to have DWARF support added to drsyms, which would then make the Windows build handle everything.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=43

From [email protected] on July 23, 2010 06:15:00

While locally working around issue #5 , I've noticed the following bug.

I think the output for (b) should be the same as (c)
or -nocheck_leaks should not print leak information at all.

(a) $ drmemory.exe -- test.exe
...
:::Dr.Memory::: 1 total, 532 byte(s) of leak(s)
...

(b) $ drmemory.exe -suppress supp.txt -- test.exe
...
:::Dr.Memory::: 1 total, 532 byte(s) of leak(s)
...
:::Dr.Memory::: 0 suppressed leak(s)
...

(c) $ drmemory.exe -suppress supp.txt -check_leaks -- test.exe
...
:::Dr.Memory::: 0 total, 0 byte(s) of leak(s)
...
:::Dr.Memory::: 1 suppressed leak(s)
...

===test.c===
#include <stdio.h>

int main() {
printf("Hello world!\n");
return 0;
}

==supp.txt==
LEAK
*!_calloc_impl
*!_calloc_crt
KERNEL32.dll!RegisterWaitForInputIdle

Original issue: http://code.google.com/p/drmemory/issues/detail?id=16

From [email protected] on August 13, 2010 10:01:18

svn checkout -r 375 http://googletest.googlecode.com/svn/trunk/ googletest
cd googletest\msvc
devenv gtest.sln /Upgrade
devenv gtest.sln /Build "Debug" /Project gtest_unittest

Crashes when run under v1.2.1 from portable zip:
C:\DrMemory-Windows-1.2.1-1\bin\drmemory.exe gtest\Debug\gtest_unittest.exe

On Win XP,
Shows "_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)" Abort/Retry/Ignore window

On Windows 2008 server,
ASSERT FAILURE (thread 9444): E:/derek/dr/win32/oss-clients/drmemory/common/heap.c:586: info->heap == INVALID_HANDLE_VALUE (conflicts in Heap for region)

Original issue: http://code.google.com/p/drmemory/issues/detail?id=26

From [email protected] on August 25, 2010 09:31:47

$ ./bin/drmemory.pl which ls
ERROR: ld.so: object 'libdynamorio.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'libdrpreload.so' from LD_PRELOAD cannot be preloaded: ignored.
README bin docs drmemory dynamorio
$ Giving up on finding logdir: assuming process 16291 died

Original issue: http://code.google.com/p/drmemory/issues/detail?id=34

From [email protected] on September 07, 2010 10:25:04

http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows&#37;20Tests&#37;20(DrMemory)/builds/2594/steps/memory&#37;20test:&#37;20remoting/logs/stdio 01:35:51 drmemory_analyze.py [ERROR]
UNADDRESSABLE ACCESS: writing 0x0011f984-0x0011f988 4 byte(s)
#1 0x006c84cf file_util::ReadFileToString base\file_util.cc:153
#2 0x0070c32d remoting::JsonHostConfig::Read remoting\host\json_host_config.cc:27
#3 0x004591fc remoting::JsonHostConfigTest_Read_Test::TestBody remoting\host\json_host_config_unittest.cc:68

01:35:51 drmemory_analyze.py [ERROR]
UNADDRESSABLE ACCESS: writing 0x0011f950-0x0011f954 4 byte(s)
#1 0x006c84cf file_util::ReadFileToString base\file_util.cc:153
#2 0x0070c32d remoting::JsonHostConfig::Read remoting\host\json_host_config.cc:27
#3 0x0045a32c remoting::JsonHostConfigTest_Write_Test::TestBody remoting\host\json_host_config_unittest.cc:92

01:35:51 drmemory_analyze.py [ERROR]
UNADDRESSABLE ACCESS: writing 0x0011f950-0x0011f954 4 byte(s)
#1 0x006c84cf file_util::ReadFileToString base\file_util.cc:153
#2 0x0070c32d remoting::JsonHostConfig::Read remoting\host\json_host_config.cc:27
#3 0x0045a52c remoting::JsonHostConfigTest_Write_Test::TestBody remoting\host\json_host_config_unittest.cc:106

I've run the test under debugger and ESP changes its value from 0x0012F99C to 0x0011F980 when execution enters ReadFileToString function.
This may be related to issue #47 since the same test crashed a in a few seconds after these false reports.

I'm investigating these reports now and will add more details later.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=49

From [email protected] on August 28, 2010 15:30:54

running base_unittests.exe from issue #251 with:
--gtest_filter="-FileVersion*:ProcessUtilTest.GetAppOutput:ReadOnlyFileUtilTest.ContentsEqual:ReadOnlyFileUtilTest.TextContentsEqual:DataPackTest.Load"

...
[----------] 5 tests from ProcessUtilTest
[ RUN ] ProcessUtilTest.SpawnChild
[ OK ] ProcessUtilTest.SpawnChild (203 ms)
[ RUN ] ProcessUtilTest.KillSlowChild
[ OK ] ProcessUtilTest.KillSlowChild (234 ms)
[ RUN ] ProcessUtilTest.SetProcessBackgrounded
[ OK ] ProcessUtilTest.SetProcessBackgrounded (47 ms)
[ RUN ] ProcessUtilTest.EnableLFH
:::Dr.Memory::: ASSERT FAILURE (thread 132132): E:/derek/dr/win32/oss-clients/drmemory/common/alloc.c:2183: !pt->expect_lib_to_fail || pt->alloc_base == NULL (free() success unexpected)

but, can't repro by just running --gtest_filter="ProcessUtilTest*:-ProcessUtilTest.GetAppOutput"

heap = 05670000, block = 0567e908

0:000> !heap
Index Address Name Debugging options enabled
1: 00160000
2: 00260000
3: 00270000
4: 00370000
5: 003a0000
6: 019b0000
7: 05670000
8: 02ff0000

it is used as a stack a couple of times:
thread initial stack: 0x05670000-0x0576e000-0x05770000, TOS=0x0576fffc
but not for any current thread

heap_tree does have the heap:
0:000> ?? *heap_tree->root->right->right
struct _rb_node_t
+0x000 parent : 0x18e3ea48
+0x004 right : 0x1a1db400
+0x008 left : 0x19e95424
+0x00c color : 1 ( BLACK )
+0x010 base : 0x05670000 "???"
+0x014 size : 0x100000
+0x018 max : (null)
+0x01c client : 0x1afaa3a4

so it's just missing the alloc

RtlpAllocateFromHeapLookaside does not call RtlAllocateHeap
instead it calls RtlpInterlockedPopEntrySList
but then RtlpActivateLowFragmentationHeap calls RtlFreeHeap w/ the result

also wondering about:
0:000> x ntdll!Rtl_Allocate_Heap*
7c96ceb9 ntdll!RtlDebugAllocateHeap =
7c919b80 ntdll!RtlReAllocateHeap =
7c9101d1 ntdll!RtlpAllocateFromHeapLookaside =
7c9100a4 ntdll!RtlAllocateHeap =
7c918f15 ntdll!RtlAllocateHeapSlowly =
7c96d24f ntdll!RtlDebugReAllocateHeap =
7c9601b0 ntdll!RtlpAllocateHeapUsageEntry =
7c9691e9 ntdll!RtlpDphShouldAllocateInPageHeap =

RtlDebugAllocateHeap calls RtlAllocateHeapSlowly
RtlAllocateHeapSlowly is long, doesn't seem to call RtlAllocateHeap...

p /x ((0x15+0x15*2)<<4) + 0x5670690
$6 = 0x5670a80

so could intercept and use the containing Heap of the arg
except need symbols:
% bin/winsyms.exe -e c:/windows/system32/ntdll.dll -s RtlpAllocateFromHeapLookaside
??

Original issue: http://code.google.com/p/drmemory/issues/detail?id=37

From [email protected] on August 05, 2010 05:06:44

On Windows XP ( r379 / r27 ), the following code crashes on the ConnectServer line:

#include <windows.h>
#include <stdio.h>
#include <Wbemidl.h>
#include <assert.h>

#pragma comment(lib, "Wbemuuid.lib")
#pragma comment(lib, "Ole32.lib")

int main() {
HRESULT hr;
::CoInitialize(NULL);
IWbemLocator *wmi_locator = NULL;

hr = ::CoCreateInstance(CLSID_WbemLocator, NULL, CLSCTX_INPROC_SERVER,
__uuidof(IWbemLocator),
reinterpret_cast<void**>(&wmi_locator));
assert(!FAILED(hr));

printf("before ConnectServer...\n");
IWbemServices *wmi_services_r = NULL;
hr = wmi_locator->ConnectServer(L"ROOT\CIMV2", NULL, NULL, 0,
NULL, 0, 0, &wmi_services_r);
printf("after ConnectServer...\n");
assert(!FAILED(hr));

wmi_locator->Release();
wmi_services_r->Release();
::CoUninitialize();
printf("DONE\n");
return 0;
}

drmemory.exe -dr_ops "-dumpcore_mask 0x8bff" -delay_frees 0 -- test.exe

Attached is the 7z'ed LDMP and the report files (200+ false reports!).

Labeling this as ToolCrash since the global.XYZ.txt file is incomplete
thus looks like it was a tool crash, not app crash.

Without "-delay_frees 0" it crashes after printing the "DONE" line and reporting 500+ reports and the global.XYZ.txt file is incomplete (ends on "assuming mmap 0x0012f000-0x00130000 is a stack" line)

Attachment: logs.7z

Original issue: http://code.google.com/p/drmemory/issues/detail?id=21

From [email protected] on August 13, 2010 07:23:36

1. Download base_unittests.exe attached to https://code.google.com/p/dynamorio/issues/detail?id=251 2) drmemory.exe -- base_unittests --gtest_filter="RecursiveDenial"

It happens on r36 and r33 on Windows XP.
I couldn't reproduce it on v1.2.1 binaries due to issue #23 .

Original issue: http://code.google.com/p/drmemory/issues/detail?id=25

From [email protected] on June 11, 2010 11:35:42

$ ctest -S tests/runsuite.cmake
CMake Error at tests/runsuite.cmake:128 (message):
cannot find DynamoRIO VMKERNEL build at
/home/timurrrr/drmemory/SVN/trunk/tests/../../../exports_vmk/cmake
Error in read script: /home/timurrrr/drmemory/SVN/trunk/tests/runsuite.cmake

I've applied the following patch to do without VMK:
Index: tests/runsuite.cmake

--- tests/runsuite.cmake ( revision 16 )
+++ tests/runsuite.cmake (working copy)
@@ -123,11 +123,11 @@
endif (NOT EXISTS "${DR_path}")
endif (NOT arg_vmk_only)

-if (UNIX)

• if (NOT EXISTS "${DRvmk_path}")
• message(FATAL_ERROR "cannot find DynamoRIO VMKERNEL build at ${DRvmk_path}")
• endif (NOT EXISTS "${DRvmk_path}")
  -endif (UNIX)
  +#if (UNIX)
  +# if (NOT EXISTS "${DRvmk_path}")
  +# message(FATAL_ERROR "cannot find DynamoRIO VMKERNEL build at ${DRvmk_path}")
  +# endif (NOT EXISTS "${DRvmk_path}")
  +#endif (UNIX)

allow setting the base cache variables via an include file

set(base_cache "")
@@ -368,18 +368,18 @@
" ON) # only run release tests for long suite
endif (NOT arg_vmk_only)
if (UNIX)

• testbuild("${name}-vmk-debug-32" OFF "

•  ${tool}
  

•  DynamoRIO_DIR:PATH=${DRvmk_path}
  

•  CMAKE_BUILD_TYPE:STRING=Debug
  

•  VMKERNEL:BOOL=ON
  

•  " OFF)
  

• testbuild("${name}-vmk-release-32" OFF "

•  ${tool}
  

•  DynamoRIO_DIR:PATH=${DRvmk_path}
  

•  CMAKE_BUILD_TYPE:STRING=Release
  

•  VMKERNEL:BOOL=ON
  

•  " ON) # only run release tests for long suite
  

• #testbuild("${name}-vmk-debug-32" OFF "

• ${tool}

• DynamoRIO_DIR:PATH=${DRvmk_path}

• CMAKE_BUILD_TYPE:STRING=Debug

• VMKERNEL:BOOL=ON

• " OFF)

• #testbuild("${name}-vmk-release-32" OFF "

• ${tool}

• DynamoRIO_DIR:PATH=${DRvmk_path}

• CMAKE_BUILD_TYPE:STRING=Release

• VMKERNEL:BOOL=ON

• " ON) # only run release tests for long suite

else (UNIX)
if ("${tool}" MATCHES "MEMORY")
# No online symbol support for cygwin yet so using separate build

Then
$ ctest -S tests/runsuite.cmake
Error(s) when building project
No tests were found!!!

RESULTS

drheapstat-debug-32: **** pre-build configure errors ****
drheapstat-release-32: **** pre-build configure errors ****
drmemory-debug-32: **** 50 build errors ****
/.../trunk/drmemory/syscall_linux.c:50:59: error: asm-i386/stat.h: No such file or directory
/.../trunk/drmemory/syscall_linux.c:78:21: error: asm/ipc.h: No such file or directory
/.../trunk/drmemory/syscall_linux.c:116:29: error: linux/umsdos_fs.h: No such file or directory
/.../trunk/drmemory/syscall_linux.c:251: error: invalid application of ‘sizeof’ to incomplete type ‘struct __old_kernel_stat’
<... and more errors ...>

Looks like Kostya had the same issues earlier but he doesn't remember whether he succeeded in building Dr.Memory for Linux: https://groups.google.com/group/drmemory-users/browse_thread/thread/9769aadd7bb197b5?pli=1

Original issue: http://code.google.com/p/drmemory/issues/detail?id=6

From [email protected] on July 22, 2010 07:16:42

On Windows XP ( r378 / r24 ), the following code

#include <windows.h>

DWORD WINAPI foo(void*) {
return 0;
}

int main() {
DWORD id = 0;
HANDLE thr = CreateThread(NULL, 0, foo, NULL, 0, &id);
WaitForSingleObject(thr, INFINITE);
return 0;
}

Gives the following report:

Error #1: UNINITIALIZED READ: reading 0x0012fb80-0x0012fc08 136 byte(s) within 0x0012fb7c-0x0012fe48
@0:00:01.016 in thread 320
system call NtCreateThread

0x7c8106f5 <KERNEL32.dll+0x106f5> KERNEL32.dll!CreateThread
??:0
0x00401054 <test.exe+0x1054> test.exe!main
z:\dr-sandbox\issues\286\test.cpp:9
0x00401271 <test.exe+0x1271> test.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle
??:0

This may be related to https://code.google.com/p/dynamorio/issues/detail?id=286

Original issue: http://code.google.com/p/drmemory/issues/detail?id=13

From [email protected] on August 12, 2010 08:42:01

1. Download base_unittests.exe attached to https://code.google.com/p/dynamorio/issues/detail?id=251 2) drmemory.exe -- base_unittests
   -> asserts right away.
   Looks like it doesn't support something done during googletest startup.

This happens on both r35 and v1.2.1 downloaded from here.

I'll continue using r33 until this is fixed.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=23

From [email protected] on July 27, 2010 11:19:22

On Windows XP ( r378 / r24 ), the following code

#include <windows.h>
#include <stdio.h>
#include <assert.h>
#pragma comment(lib, "user32.lib")

#define kWndClass "Test wnd class name"

LRESULT CALLBACK WndProcThunk(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) {
return DefWindowProc(hwnd, message, wparam, lparam);
}

int main() {
HWND hwnd = NULL;
HINSTANCE hinst = GetModuleHandle(NULL);

WNDCLASSEX wc = {0};
wc.cbSize = sizeof(wc);
wc.lpfnWndProc = WndProcThunk;
wc.hInstance = hinst;
wc.lpszClassName = kWndClass;
RegisterClassEx(&wc);

hwnd = CreateWindow(kWndClass, 0, 0, 0, 0, 0, 0, HWND_MESSAGE, 0, hinst, 0);
assert(hwnd);
DestroyWindow(hwnd);
UnregisterClass(kWndClass, GetModuleHandle(NULL));
}

Gives 7 error reports (attached).

Example:
Error #4: UNADDRESSABLE ACCESS: reading 0x0012f4c8-0x0012f4c9 1 byte(s) within 0x0012f4c8-0x0012f4cc
@0:00:03.750 in thread 2276
0x7e4184ce <USER32.dll+0x84ce> USER32.dll!?
??:0
0x5ad746f6 <UxTheme.dll+0x46f6> UxTheme.dll!GetThemeColor
??:0
0x5ad74693 <UxTheme.dll+0x4693> UxTheme.dll!GetThemeColor
??:0
0x5ad7a63e <UxTheme.dll+0xa63e> UxTheme.dll!IsThemePartDefined
??:0
0x5ad7985d <UxTheme.dll+0x985d> UxTheme.dll!IsThemeActive
??:0
0x5ad7960a <UxTheme.dll+0x960a> UxTheme.dll!IsThemeActive
??:0
0x5ad7ad7b <UxTheme.dll+0xad7b> UxTheme.dll!Ordinal25
??:0
0x7e427f06 <USER32.dll+0x17f06> USER32.dll!SetProcessWindowStation
??:0
0x7e428069 <USER32.dll+0x18069> USER32.dll!GetGUIThreadInfo
??:0
0x7c90e473 <ntdll.dll+0xe473> ntdll.dll!KiUserCallbackDispatcher
??:0
0x7e42e442 <USER32.dll+0x1e442> USER32.dll!GetScrollInfo
??:0
0x7e42e4dc <USER32.dll+0x1e4dc> USER32.dll!CreateWindowExA
??:0
0x004010b7 <test.exe+0x10b7> test.exe!main
Z:\dr-sandbox\issues\new\test.c:23
0x00401c70 <test.exe+0x1c70> test.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle
??:0

Attachment: results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=17

From [email protected] on September 07, 2010 08:49:48

This has happened on Chromium remoting_unittests, http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows&#37;20Tests&#37;20(DrMemory)/builds/2586/steps/memory&#37;20test:&#37;20remoting/logs/stdio [----------] 4 tests from ClientConnectionTest
[ RUN ] ClientConnectionTest.SendUpdateStream
[ OK ] ClientConnectionTest.SendUpdateStream (860 ms)
[ RUN ] ClientConnectionTest.StateChange
[ OK ] ClientConnectionTest.StateChange (265 ms)
[ RUN ] ClientConnectionTest.ParseMessages
11:47:50 common.py [INFO] process ended, did not time out
11:47:50 common.py [INFO] flushing stdout
11:47:50 common.py [INFO] collecting result code
...
11:47:50 drmemory_analyze.py [ERROR]
ASSERT FAILURE (thread 2480): common\alloc.c:1243: !TEST(MALLOC_VALID, old_e->flags) (internal error in malloc tracking)

I'll try to create a reproducer for that

Original issue: http://code.google.com/p/drmemory/issues/detail?id=47

From [email protected] on June 08, 2010 15:08:34

Issue 309 : fix wrong assertion in suppression matcher

stats: 56 diff lines

Original issue: http://code.google.com/p/drmemory/issues/detail?id=1

From [email protected] on September 06, 2010 11:30:18

This has happened on net_unittests, http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows&#37;20Tests&#37;20(DrMemory)/builds/2581/steps/memory&#37;20test:&#37;20net_2/logs/stdio I'll try to pack net_unittests for you and/or create a short repro

Original issue: http://code.google.com/p/drmemory/issues/detail?id=46

From [email protected] on June 10, 2010 11:38:27

Issue 309 : fix wrong assertion in suppression matcher

stats: 67 diff lines

Original issue: http://code.google.com/p/drmemory/issues/detail?id=4

From [email protected] on June 22, 2010 11:38:41

Currently assert messages go to message box if Dr.Memory is run without "-quiet"
and only to global.PID.txt in the other case.
If you run the current version on a bot you either have to manually dismiss message boxes or you miss assertions or you have to re-parse global.PID.txt file once again.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=7

From [email protected] on July 22, 2010 08:14:06

On Win XP, r378 / r24 give false reports on the following code:

#define _CRT_RAND_S
#include <windows.h>
#include <assert.h>
#include <stdlib.h>
#include <stdio.h>

unsigned int Rand() {
unsigned int v = 1;
assert(rand_s(&v) == 0);
return v;
}

int main(void) {
printf("%d\n", Rand());
return 0;
}

gives the following report:

Error #1: UNINITIALIZED READ: reading 0x0012ff1c-0x0012ff20 4 byte(s)
@0:00:02.016 in thread 4772
0x00808315 <ADVAPI32.dll+0x8315> ADVAPI32.dll!SystemFunction036
??:0
0x008082f3 <ADVAPI32.dll+0x82f3> ADVAPI32.dll!SystemFunction036
??:0
0x008082b6 <ADVAPI32.dll+0x82b6> ADVAPI32.dll!SystemFunction036
??:0
0x00401a1f <test.exe+0x1a1f> test.exe!rand_s
f:\dd\vctools\crt_bld\self_x86\crt\src\rand_s.c:107
0x00401068 <test.exe+0x1068> test.exe!main
z:\dr-sandbox\issues\new\test.cpp:14
0x00401d88 <test.exe+0x1d88> test.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle
??:0

Error #2: UNINITIALIZED READ: reading 0x0012ff18-0x0012ff19 1 byte(s)
@0:00:02.016 in thread 4772
0x00808334 <ADVAPI32.dll+0x8334> ADVAPI32.dll!SystemFunction036
??:0
0x008082f3 <ADVAPI32.dll+0x82f3> ADVAPI32.dll!SystemFunction036
??:0
0x008082b6 <ADVAPI32.dll+0x82b6> ADVAPI32.dll!SystemFunction036
??:0
0x00401a1f <test.exe+0x1a1f> test.exe!rand_s
f:\dd\vctools\crt_bld\self_x86\crt\src\rand_s.c:107
0x00401068 <test.exe+0x1068> test.exe!main
z:\dr-sandbox\issues\new\test.cpp:14
0x00401d88 <test.exe+0x1d88> test.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle
??:0

These can be suppressed by the following suppression:
UNINITIALIZED READ
ADVAPI32.dll!SystemFunction036
ADVAPI32.dll!SystemFunction036
ADVAPI32.dll!SystemFunction036
*!rand_s

Original issue: http://code.google.com/p/drmemory/issues/detail?id=15

From [email protected] on August 25, 2010 07:12:23

$ ./bin/drmemory.pl ls
application ls not found
usage: ./bin/drmemory.pl [options] -- [args ...]

$ ./bin/drmemory.pl -- ls
application ls not found
usage: ./bin/drmemory.pl [options] -- [args ...]

$ ./bin/drmemory.pl which ls
ERROR: ld.so: object 'libdynamorio.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'libdrpreload.so' from LD_PRELOAD cannot be preloaded: ignored.
README bin docs drmemory dynamorio
$ Giving up on finding logdir: assuming process 16291 died

Original issue: http://code.google.com/p/drmemory/issues/detail?id=33

From [email protected] on June 09, 2010 12:14:31

Issue 309 : fix wrong assertion in suppression matcher

stats: 66 diff lines

Original issue: http://code.google.com/p/drmemory/issues/detail?id=3

From [email protected] on August 30, 2010 09:22:42

As of r41 / r414 , the following code gives 2 unaddr and 19 uninit and 1 invalid heap heports:

#include <windows.h>
#include <assert.h>
#pragma comment(lib, "winspool.lib")

int main() {
HANDLE printer;
assert(OpenPrinter(NULL, &printer, NULL));
ClosePrinter(printer);
return 0;
}

cl /Zi test.cpp && drmemory.exe test.exe

I'll temporary suppress everything under WINSPOOL.DRV for Chromium.

Do you think it makes sense to check memory errors inside WINSPOOL at all?

Attachment: results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=40

From [email protected] on July 22, 2010 06:40:15

On Windows XP, the following code gives 200+ reports:

#include <windows.h>
#include <shellapi.h>

#pragma comment(lib, "shell32.lib")

int main(void) {
SHFILEOPSTRUCT file_operation = {0};
file_operation.wFunc = FO_DELETE;
file_operation.pFrom = "test.txt\0\0";
file_operation.fFlags = FOF_NOERRORUI | FOF_SILENT | FOF_NOCONFIRMATION;
file_operation.fFlags |= FOF_NORECURSION | FOF_FILESONLY;
SHFileOperation(&file_operation);
return 0;
}

cl test.c
help more >test.txt || drmemory.exe -- test.exe

Sample report file is attached.

Attachment: results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=12

From [email protected] on June 29, 2010 09:56:49

I have leak callstacks off by default to save memory but there is a problem.
Leak suppression can only happen when callstacks are available:
so by default (i.e., -no_check_leaks) they will not be suppressed
and will show up in the leak count error summary which is not
ideal. This can be seen in the winthreads test with its
(forthcoming: DR issue #286) default-suppress leak.

Perhaps leak callstacks should just be on by default.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=8

From [email protected] on June 29, 2010 11:02:36

Dr. Memory r19 + Dynamorio r363 work fine.

When I update Dr. Memory to r20 ( https://code.google.com/p/drmemory/source/detail?r=20 )
and re-build (nmake clean && cmake ... && nmake install),
I get the following error when trying to run any executable:
WARNING: unable to locate results file since can't open .../logs/resfile.XXXX: 2"

At first I thought the problem was my AV software but disabling it didn't help.
This is happening on Windows XP.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=9

From [email protected] on August 12, 2010 09:56:37

For example, currently you can type the following suppression:

UNINITIALIZED READ
...
*!rand_s
...

and though it can't match anything, it is accepted.

I think we should have a strict suppression syntax, e.g.
all lines are
XYZ!ABC
or
system call XYZ
or
<XYZ+0x[0-9a-fA-F*]+>

Original issue: http://code.google.com/p/drmemory/issues/detail?id=24

From [email protected] on August 11, 2010 12:07:08

drmemory.exe -- racecheck_unittest-windows-x86-O0.exe --gtest_filter="_Register_Wait*"
<the .exe file is attached>
...
:::Dr.Memory::: ERRORS FOUND:
:::Dr.Memory::: 272 unique, 4942 total unaddressable access(es)

...

This may probably be related to some magic googletest does with exception handling or something.

Source code: https://code.google.com/p/data-race-test/source/browse/trunk/unittest/windows_tests.cc?spec=svn2375&r=2173#148 + headers and .cc files around

Building the test (from Cygwin which is run from VS command prompt):
svn checkout http://data-race-test.googlecode.com/svn/trunk/ data-race-test
cd data-race-test/unittest
make
-> will produce data-race-test/unittest/bin/memory_unittest-windows-x86-O0.exe

This may be related to issue #11 (there is at least one _chkstk report).

I think I saw 2 "WARNING: unknown region ..." lines with --gtest_filter="Wait" but couldn't reproduce it.

Attachment: tsan_test.zip results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=22

From [email protected] on July 22, 2010 07:49:10

On Windows XP, the following code gives 30+ reports:

#include <windows.h>
#include <userenv.h>

#pragma comment(lib, "userenv.lib")
#pragma comment(lib, "advapi32.lib")

#include <assert.h>
#include <stdio.h>

int main(void) {
HANDLE token;
assert(OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &token));

STARTUPINFO startup_info = {0};
startup_info.cb = sizeof(startup_info);

void* env_block = NULL;
assert(CreateEnvironmentBlock(&env_block, token, FALSE));

PROCESS_INFORMATION proc_info = {0};
BOOL launched = CreateProcessAsUser(token, NULL,
"C:\Windows\system32\ping.exe www.google.com",
NULL, NULL, FALSE, CREATE_UNICODE_ENVIRONMENT,
env_block, NULL, &startup_info, &proc_info);
DestroyEnvironmentBlock(env_block);

if (!launched) {
printf("FAIL\n");
return 1;
}

CloseHandle(proc_info.hThread);
CloseHandle(proc_info.hProcess);
printf("OK\n");
return 0;
}

cl /Zi test.cpp && drmemory.exe -- test.exe

Attachment: results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=14

From [email protected] on August 04, 2010 06:53:58

I've found this assert running a test similar to the repro from issue #13 in googletest framework.

drmemory.exe -dr_ops "-dumpcore_mask 0x8bff" -- memory_unittest-windows-x86-O0.exe --gtest_filter="Thread"

Attached are the dumpcore, results and global.XYZ.txt files.

Also I saw the following assert on the same test:
report.c:1084: err->id != 0 (duplicate should have id)

This has been introduced by r25 - r26

Original issue: http://code.google.com/p/drmemory/issues/detail?id=19

From [email protected] on September 14, 2010 08:45:53

It's very useful in at least two cases:
a) Getting a list unused suppressions.
Usually they suppress stacks for fixed or out-of-date bugs which need to be closed
b) Checking the sanity of the tool, e.g. see "Chromium tools sanity tests" http://src.chromium.org/viewvc/chrome/trunk/src/base/tools_sanity_unittest.cc?revision=50352&view=markup - after each run of these tests we check that each suppression
with a specific name prefix matches exactly one error report.

This feature requires addition of "suppression names".

Derek, what do you think about tweaking the suppression format to something with names, e.g. Valgrindish ?
{
<suppression_name> # e.g. bug_23
UNADDRESSABLE ACCESS

}

Original issue: http://code.google.com/p/drmemory/issues/detail?id=50

From [email protected] on July 21, 2010 12:13:05

I see a large number of _chkstk false reports on Chromium unittests.

According to MSDN, http://msdn.microsoft.com/en-us/library/ms648426(VS.85).aspx ,
"_chkstk routine is called when the local variables exceed 4K bytes; for x64 compilers it is 8K."

In Chromium, most of these reports come from testing::FormatCountableNoun
( https://code.google.com/p/googletest/source/browse/trunk/src/gtest.cc?spec=svn445&r=443#2474 )
and these are probably caused by 4K buffer in String::Format
( https://code.google.com/p/googletest/source/browse/trunk/src/gtest.cc?spec=svn445&r=443#1713 )

I couldn't create a small reproducer for the issue at the first try, will try later.

An easy solution is a suppression but probably it's worth investigating. Can this be related to something else?

Original issue: http://code.google.com/p/drmemory/issues/detail?id=11

From [email protected] on August 30, 2010 07:59:25

As a result, you can't modify the suppression file on the Chromium build bot while it is running a test.
It'd be useful to close the file handle once it is read so it's possible to modify the suppression file without stopping and restarting the bot.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=39

From [email protected] on August 13, 2010 11:24:19

On r33 /v1.2.1 on Windows XP

#include <stdlib.h>

int main() {
_putenv("VAR=VALUE");
return 0;
}

built with "cl /Zi test.cpp" gives the following report:

Error #1: UNADDRESSABLE ACCESS: writing 0x000117f8-0x000117f9 1 byte(s) within 0x000117f8-0x000117fc
@0:00:01.219 in thread 14188
0x7c9022ad <ntdll.dll+0x22ad> ntdll.dll!memmove
??:0
0x7c923a1a <ntdll.dll+0x23a1a> ntdll.dll!RtlDestroyEnvironment
??:0
0x7c83351a <KERNEL32.dll+0x3351a> KERNEL32.dll!SetEnvironmentVariableA
??:0
0x00402111 <test.exe+0x2111> test.exe!__crtsetenv
f:\dd\vctools\crt_bld\self_x86\crt\src\setenv.c:338
0x00401156 <test.exe+0x1156> test.exe!_putenv_helper
f:\dd\vctools\crt_bld\self_x86\crt\src\putenv.c:268
0x0040125a <test.exe+0x125a> test.exe!_putenv
f:\dd\vctools\crt_bld\self_x86\crt\src\putenv.c:78
0x0040101d <test.exe+0x101d> test.exe!main
z:\dr-sandbox\issues\putenv\test.cpp:4
0x004014ec <test.exe+0x14ec> test.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle
??:0

Original issue: http://code.google.com/p/drmemory/issues/detail?id=28

From [email protected] on July 21, 2010 12:05:22

On Windows XP, build the following file:

#include <windows.h>
#pragma comment(lib, "User32.lib")
int main(void) {
NONCLIENTMETRICS metrics;
ZeroMemory(&metrics, sizeof(NONCLIENTMETRICS));
metrics.cbSize = sizeof(NONCLIENTMETRICS);
SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &metrics, 0);
return 0;
}

$ cl test.c
$ drmemory.exe test.exe # r378 / r24 ...

Please note that I've seen these UxTheme reports in a few places, so this maybe related to a larger issue.

Attachment: report.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=10

From [email protected] on August 27, 2010 08:01:29

svn checkout -r 375 http://googletest.googlecode.com/svn/trunk/ googletest
cd googletest\msvc
devenv gtest.sln /Upgrade
devenv gtest.sln /Build "Debug" /Project gtest_unittest

drmemory.exe -- gtest\Debug\gtest_unittest.exe --gtest_filter="Color"
Error #18: UNINITIALIZED READ: reading 0x0012f910-0x0012f914 4 byte(s) within 0x0012f910-0x0012f914
@0:00:10.891 in thread 41124
system call NtContinue

0x00590f10 <gtest_unittest.exe+0x190f10> gtest_unittest.exe!DebuggerProbe
??:0
0x00590e9a <gtest_unittest.exe+0x190e9a> gtest_unittest.exe!DebuggerKnownHandle
??:0
0x0058d7d6 <gtest_unittest.exe+0x18d7d6> gtest_unittest.exe!_flsbuf
f:\dd\vctools\crt_bld\self_x86\crt\src_flsbuf.c:151
0x00570a95 <gtest_unittest.exe+0x170a95> gtest_unittest.exe!fputc
f:\dd\vctools\crt_bld\self_x86\crt\src\fputc.c:52
0x0055c8c1 <gtest_unittest.exe+0x15c8c1> gtest_unittest.exe!std::_Fputc
f:\dd\vctools\crt_bld\self_x86\crt\src\fstream:81
0x0055c418 <gtest_unittest.exe+0x15c418> gtest_unittest.exe!std::basic_filebuf<char,std::char_traits >::overflow
f:\dd\vctools\crt_bld\self_x86\crt\src\fstream:261
0x004c8cbb <gtest_unittest.exe+0xc8cbb> gtest_unittest.exe!std::basic_streambuf<char,std::char_traits >::xsputn
c:\program files\microsoft visual studio 8\vc\include\streambuf:379
0x004ce535 <gtest_unittest.exe+0xce535> gtest_unittest.exe!std::operator<<std::char_traits
c:\program files\microsoft visual studio 8\vc\include\ostream:768
0x005cc21d <gtest_unittest.exe+0x1cc21d> gtest_unittest.exe!main
c:\googletest\src\gtest_main.cc:35
0x0056ad53 <gtest_unittest.exe+0x16ad53> gtest_unittest.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:327
0x0056ab0d <gtest_unittest.exe+0x16ab0d> gtest_unittest.exe!mainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:195
0x7c817077 <KERNEL32.dll+0x17077> KERNEL32.dll!RegisterWaitForInputIdle

Also I saw similar reports on googletest in Chromium: http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows&#37;20Tests&#37;20(DrMemory)/builds/2330/steps/memory&#37;20test:&#37;20media/logs/stdio UNINITIALIZED READ: reading 0x0012f9ac-0x0012f9b0 4 byte(s) within 0x0012f9ac-0x0012f9b0
#1 <sys.call> NtContinue
#2 0x009b77b0 DebuggerProbe
#3 0x009b774a DebuggerKnownHandle
#4 0x0088dd7c testing::internal::posix::IsATTY testing\gtest\include\gtest\internal\gtest-port.h:1287
#5 0x0088dc1e testing::internal::ColoredPrintf testing\gtest\src\gtest.cc:2622
#6 0x0088de27 testing::internal::PrettyUnitTestResultPrinter::OnTestIterationStart testing\gtest\src\gtest.cc:2703
#7 0x0088f477 testing::internal::TestEventRepeater::OnTestIterationStart testing\gtest\src\gtest.cc:2977

I think it's rather an uninit inside DebuggerKnownHandle than NtContinue reading too much.
Still needs investigation IMO.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=36

From [email protected] on August 03, 2010 11:17:30

On Windows XP ( r378 / r24 ), the following code

#include <windows.h>
#include <Objbase.h>
#include <stdio.h>

#pragma comment(lib, "Ole32.lib")

int main() {
CoInitialize(NULL);
CoUninitialize();
printf("PASS\n");
}

gives ~30 reports (example is attached)

Original issue: http://code.google.com/p/drmemory/issues/detail?id=18