https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #6 from Michael Stefaniuc mstefani@winehq.org --- Thanks, I see what is going on: At one point it starts allocating 42 MB sized sound buffers until it runs out of MEM:
0024:trace:dmusic:wave_download_to_dsound 0235B550, 003F3564, 023A0F4C ... 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032) ... 0024:trace:dsound:secondarybuffer_create (003F4128,0031F9F0,0031F9EC) 0024:trace:dsound:secondarybuffer_create Created buffer at 02388FC0 0024:trace:dsound:secondarybuffer_create capf = 0x00000a00, device->drvcaps.dwFlags = 0x00000f5f 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 02a20000
$ grep -F 'dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes' CK_dmusic.log | sort | uniq -c 15 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=0) 16 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=176400) 15 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=4) 28 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032) 1 0168:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=0)
All but the last failing buffer create are followed by a secondarybuffer_destroy call:
$ grep -P '(dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes|secondarybuffer_destroy)' CK_dmusic.log ... 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032) 0120:trace:dsound:secondarybuffer_destroy (02388FC0) released 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032) 0120:trace:dsound:secondarybuffer_destroy (02388FC0) released 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032) 0120:trace:dsound:secondarybuffer_destroy (02388FC0) released 0024:trace:dsound:DirectSoundDevice_CreateSoundBuffer (bufferbytes=44140032)
So we don't leak secondary dsound buffers but we leak the wave COM objects as I see no single wave_Release() call in the log:
$ grep wave_Release CK_dmusic.log $
Assuming the wave->data member matches the size of the secondary dsound buffer we've accumulated almost 1.2 GB of wave data in memory. With the 2 / 2 GB split on 32 bit we're running out of address space for the application.