APP ASSERT _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) on operator delete with /MTd

[derekbruening]

From timurrrr@google.com 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

[derekbruening]

From timurrrr@google.com on August 13, 2010 07:37:44

The same test starts OK with r33 and crashes silently on the first test
and passes under r33 if run with --gtest_filter="-Death"

Raising priority to "Critical" since Chromium tests can't start at all with r36 /v1.2.1

Labels: -Priority-Medium Priority-Critical

[derekbruening]

From derek.br...@gmail.com on August 18, 2010 12:54:03

I can repro the XP _BLOCK_TYPE_IS_VALID app assert w/ a small test.

The problem is that msvc operator delete makes assumptions about malloc
layout and goes and reads the malloc header.

The Dr. Memory test suite is almost exclusively C, with little C++, which
is one reason I didn't see this issue earlier. I have a small test case
that reproduces the problem that I will add to the suite.

My planned solution is to try and detect dbgcrt, not use redzones on those
heap objects, and add exceptions for operator delete accessing
unaddressable memory in the dbgcrt header. IMHO this is an abstraction
violation on the part of msvc, tying together delete and malloc such that
malloc cannot be modified or replaced.

Locating operator delete will require augmenting drsyms to either iterate
or search, as there are multiple "operator delete" symbols, and
un-decorating doesn't seem to make a difference.

[derekbruening]

From timurrrr@google.com on August 18, 2010 14:21:45

Can you please submit the repro to the SVN?

Is it difficult to make the new redzone algorithm commited in r34 / r35 disabled under a flag so we can use Dr.Memory trunk on C++ code at the cost of false negatives? Or maybe even create a branch for r34 / r35 and revert these revisions in trunk... What do you think?

Locally I use git so I can work on a 'head' revision with r34 / r35 excluded but that makes it difficult to publish binaries without source code into Chromium SVN.
i.e. I can publish the binaries but I can't easily tell people how can they build the same version of Dr.Memory locally.
After all, I don't want to fork the Dr. Memory source code, so putting a modified copy of trunk into Chromium SVN is not an option.

[derekbruening]

From derek.br...@gmail.com on August 18, 2010 14:47:28

you can try running with the Dr. Memory options "-redzone_size 0 -no_size_in_redzone" and r35 may well work fine

I pasted below a repro test. I have what I believe is the full fix, under which this test as well as base_unittests (w/ a filter) now run correctly. I hope to check it in within a day.

my repro test on xp hits the same app assert you cite above.
I have not seen the assert on heap.c:586: "info->heap == INVALID_HANDLE_VALUE" in the title, which you say you only saw on Server 2008 (I'm assuming this is pre- R2 , i.e., Vista codebase, not Win7)? I'm not sure whether that's a separate problem.

---

class hasdtr {
public:
hasdtr() { x = new int[7]; }
~hasdtr() { delete[] x; }
int *x;
int y;
char z;
};

int main()
{
hasdtr *has = new hasdtr[4];
has[0].y = 0;
delete [] has;
}

[derekbruening]

From timurrrr@google.com on August 19, 2010 03:20:26

you can try running with the Dr. Memory options "-redzone_size 0 -no_size_in_redzone" and r35 may well work fine
Thanks for the tip!

Yes, the Server 2008 is pre- R2 .
Let's see if the info->heap assert goes away after your fix.

[derekbruening]

From derek.br...@gmail.com on August 20, 2010 16:03:04

This is now fixed in:
Dr. Memory r37 DynamoRIO r410 However I recommend going to DynamoRIO r413 as I also fixed several other issues seen in base_unittests.exe ( issue #25 along with some other private library isolation issues). With r37 + r413 base_unittests.exe (was testing with --gtest_filter="Time*") now works on my XP VM.

Can you verify in your setup? Can you open a separate Issue if the heap.c assert remains?

Summary: APP ASSERT _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) on operator delete with /MTd
Status: Fixed

[derekbruening]

From derek.br...@gmail.com on August 20, 2010 16:11:40

Once you verify I'll put out a new release 1.2.2 since this is a pretty big bug

[derekbruening]

From timurrrr@google.com on August 23, 2010 05:39:08

This works fine on base_unittests but a possibly related assert appeared on googletest, see issue #32 .

Status: Verified

[derekbruening]

From timurrrr@google.com on August 23, 2010 05:49:33

Issue 23 has been merged into this issue.