There have been a few bug reports... http://bugs.winehq.org/show_bug.cgi?id=23902 and http://bugs.winehq.org/show_bug.cgi?id=24131 .
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.
Hi, 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) ret=7dfb31c2 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 WINEDEBUG=warn+heap. 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 ret=7dfb2382 ... 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b 0009:Ret KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b 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. W.