3Dmark2001se & heap corruption

Hi,

as there is a strong Valgrind wave these days ;) and i failed to
find the problem myself here is a little exercise for anyone
interested:

1. WINEDEBUG=warn+heap wine 3DMark2001SE.exe

2. Under selected test -> (click) Clear -> (tab) Custom -> (check)
"Game2 Dragothic Low Detail" -> OK

3. (click) Benchmark

At the end, console is flooded by many:

Heap 0x110000: block 0x2c41070 tail overwritten at 0x2c410a1 (byte
0/15 == 0x00)

Heap 0x110000: block 0x1c46b08 tail overwritten at 0x1c46b39 (byte
0/39 == 0x00)

W.

Hi,

i was able to narrow the problem:

0009:CALL MFC42.823() ret=00ae484e

0009:Call msvcrt.malloc(00000031) ret=5f40384f

0009:Call ntdll.RtlAllocateHeap(00110000,00000000,00000031)
ret=7ea60413

0009:trace:heap:RtlAllocateHeap (0x110000,70000062,00000031):
returning 0xc11c70

0009:Ret  ntdll.RtlAllocateHeap() retval=00c11c70 ret=7ea60413

0009:Ret  msvcrt.malloc() retval=00c11c70 ret=5f40384f

0009:RET  MFC42.823() retval=00c11c70 ret=00ae484e

0009:CALL MFC42.825() ret=003b16b5

0009:Call msvcrt.free(00c11c50) ret=5f40388b

0009:Call ntdll.RtlFreeHeap(00110000,00000000,00c11c50) ret=7ea603d4

0009:err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0xc11c70
tail overwritten at 0xc11ca1 (byte 0/15 == 0x00)

Is that somehow useful?

W.

[Henri Verbeet]

On 23 January 2011 00:11,   wrote:
> Is that somehow useful?

Are there any calls in between? It may just be an application bug.

> > Is that somehow useful?
>
> Are there any calls in between? It may just be an
> application bug.

No, it's complete and taken with WINEDEBUG=+all.

Is there any way to verify such heap corruption on real windows?

W.

[Henri Verbeet]

On 23 January 2011 09:03,   wrote:
> > > Is that somehow useful?
> >
> > Are there any calls in between? It may just be an
> > application bug.
>
> No, it's complete and taken with WINEDEBUG=+all.
>
> Is there any way to verify such heap corruption on real windows?

Not easily, I think. There are certainly tools like Valgrind for
Windows, but I'm not sure if there are any free ones. If there's no
Wine code being executed between the allocation and the free it seems
unlikely to me that it's a problem in Wine though.

[Jeff Zaroyko]

On Mon, Jan 24, 2011 at 6:42 AM, Henri Verbeet  wrote:
> On 23 January 2011 09:03,   wrote:
> > Is there any way to verify such heap corruption on real windows?
>
> Not easily, I think. There are certainly tools like Valgrind for
> Windows, but I'm not sure if there are any free ones. If there's no
> Wine code being executed between the allocation and the free it seems
> unlikely to me that it's a problem in Wine though.

This one is free (LGPL) http://dynamorio.org/drmemory.html
IBM has evaluation versions of Rational Purify too.

Jeff

[Vitaliy Margolen]

On 01/23/2011 01:03 AM, [e-mail] wrote:
> > > Is that somehow useful?
> >
> > Are there any calls in between? It may just be an
> > application bug.
>
> No, it's complete and taken with WINEDEBUG=+all.

Wine by default hides internal calls to many system dlls. See 
RelayFromExclude key.

Vitaliy.