Re: Help with 6120d7cc145, causing bugs

wylda at wylda at
Fri Aug 27 06:52:53 CDT 2010

> There have been a few bug reports...
> and 
> .
> It seems that in some relatively rare sound
> setups, an inappropriate sound element gets fed in to
> filllines_no_master which leads to a crash on audio initialize.


i put eyes & fingers into a code, which is bad. People like me,
should never do such things, but it just shows my desperateness
around this problem. Am i correct when saying:

HEAP is allocated begining at 0x004e2b58 and 1260bytes long:
0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec)
0009:Ret  ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2

so HEAP ends up at 0x004E3043 followed by 12 "safety bytes"
(starting at 0x004e3044), because i run the app with

This allocation is shortly followed and used by:
0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d5807e8
"Headphone",ffffffff,004e2b58,00000020) ret=7dfb2382
0009:Ret  KERNEL32.MultiByteToWideChar() retval=0000000a


0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18
"Digital",ffffffff,004e3044,00000020) ret=7dfb268b
0009:Ret  KERNEL32.MultiByteToWideChar() retval=00000008

So this "D" is written to a place (0x004e3044), where it shouldn't
be ("safety bytes").

At the end of application run, the wine complains:
0009:Call ntdll.RtlFreeHeap(00110000,00000000,004e2b58) ret=7dfb3778
err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x4e2b58 tail
overwritten at 0x4e3044 (byte 0/12 == 0x44)

And this 0x44 stands for "D" from ascii? Mentioned address 0x4e2b58
appears only in the begining (allocation) and at the end (free).

Is this helpful somehow? What should i do something next?

Thanks in advance for any help. Longer log attached.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: heap_corruption.txt
URL: <>

More information about the wine-devel mailing list