Hello,
it took me a while, but I got some more info.
Michael Karcher wrote:
> So you should find out where the HeapAlloc call was issued from that
> returned 0x6d50028. If it was from a wine dll, that dll might need to be
> fixed to ensure more strict alignment (might be some kind of audio
> buff
Alexandre Julliard wrote:
> Probably the app expects some heap block to be 16-byte aligned, and uses
> MMX vector functions that crash on unaligned data. I guess you need to
> figure out where the block comes from, and why it would always be
> aligned on Windows. Maybe it's large enough that Window
Michael Karcher wrote:
> Have you tried to run with warn+heap? In that case, on each
> HeapAlloc/HeapFree, heap integrity will be checked. Also freed blocks
> are directly overwritten with dummy data. The behaviour of warn+heap
> might be insightful.
warn+heap does not produce any additional mess
> This sounds like a segment / Boundry issue... how far up does it repeat
> this action? or have you tried??? is it an even number of blocks that the
> error does not occur?
I tried this: I added DWORD reserved[N] to SUBHEAP and tested various values of
N. Odd numbers trigger an assertion due to
Hello,
when trying to fix an issue with Guitar Rig 3 on Wine (Bug 10129, "Guitar Rig 3
crashes"), I found out something odd: The crash is affected by the size of the
SUBHEAP structure in dlls/ntdll/heap.c. Just by adding 8 unused bytes to
SUBHEAP, GR3 does not crash anymore. Add another 8 bytes
Dmitry Timoshkov wrote:
>"Zachary Goldberg" wrote:
>
>> Your patch is more likely to be accepted if it comes with a test which
>> works on windows, didnt pass in wine before but passes now and
>> demonstrates why the new behavior is correct.
>
> There is no need for a test since that's not reall
