https://bugs.winehq.org/show_bug.cgi?id=56117
Bug ID: 56117 Summary: Celtic Kings runs out of memory in mere seconds when music is enabled Product: Wine Version: 8.18 Hardware: x86-64 URL: https://archive.org/download/celtic-kings/Celtic%20Kin gs.zip OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: dmusic Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: rbernon@codeweavers.com Regression SHA1: 7a678903fbe9b384e97b23bc8cb73c9239616054 Distribution: ArchLinux
Created attachment 75783 --> https://bugs.winehq.org/attachment.cgi?id=75783 terminal output
Audio never worked in the game without native directmusic and this has not changed with the more complete directmusic implementation in recent Wine.
The problem is that the game runs out of memory in about 15 seconds just while idling in the main menu.
Some kind of memory leak first appeared in Wine-8.18 after commit 7a678903fbe9b384e97b23bc8cb73c9239616054 dmime: Implement IDirectMusicPerformance_GetNotificationPMsg.
It was less severe and allowed me to play the tutorial for a couple minutes then the game quit abruptly. For example I can see in htop that the memory consumption of Celtic Kings.exe grows steadily whenever I issue a move command for my character.
In Wine-8.19 the issue became more severe: the game runs out of memory in 10-15 seconds while idling in the main menu when music is enabled (no user interaction is needed). This is due to commit d5e156fa7fc9ff47c1c99af342047319f0f23bfa dmime: Rewrite message thread with a condition variable.
Can be reproduced with the demo version.
Tested with wine-9.0-rc3-6-g91a29134ff3.
https://bugs.winehq.org/show_bug.cgi?id=56117
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@winehq.org
--- Comment #1 from Michael Stefaniuc mstefani@winehq.org --- Should be fixed now with the merged https://gitlab.winehq.org/wine/wine/-/merge_requests/4783
https://bugs.winehq.org/show_bug.cgi?id=56117
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |68325b385847fd4619fb90b7a64 | |b8b66b894f134 CC| |dark.shadow4@web.de
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Confirming fixed by https://gitlab.winehq.org/wine/wine/-/commit/68325b385847fd4619fb90b7a64b8b6...
Memory still creeps up, but from time to time it jumps back down again, so it doesn't seem like it leaks anymore.
https://bugs.winehq.org/show_bug.cgi?id=56117
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED
--- Comment #3 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Michael Stefaniuc from comment #1)
Should be fixed now with the merged https://gitlab.winehq.org/wine/wine/-/merge_requests/4783
Sadly the commit fixes the problem only in the demo version. The full version of the game (GOG version) still has the reported problem: the game runs out of memory in a couple seconds in the main menu. Can I give you any debug logs of the full version ?
Reopened.
wine-9.0-rc3-22-gdef5e1a61d8
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #4 from Michael Stefaniuc mstefani@winehq.org --- The standard DMusic debug list should do: WINEDEBUG=+seh,+dsound,+dsound3d,+dswave,+dmband,+dmcompos,+dmdump,+dmfile,+dmfileraw,+dmime,+dmloader,+dmobj,+dmscript,+dmstyle,+dmsynth,+dmusic
If that gets too big you can try dropping "+dmfileraw"
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 75831 --> https://bugs.winehq.org/attachment.cgi?id=75831 Celtic Kings full version dmusic debug log (uncompressed 5.3 M)
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.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #7 from Rémi Bernon rbernon@codeweavers.com --- The game is leaking references to the segments. I'm not sure if it expects IDirectMusicLoader8_ReleaseObjectByUnknown to destroy the object but that sounds suspicious, and a larger impacting change that I'm a bit afraid of adding.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #8 from Rémi Bernon rbernon@codeweavers.com --- I think https://gitlab.winehq.org/wine/wine/-/merge_requests/4805 mitigates the leak, avoiding the large data allocations.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #9 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Rémi Bernon from comment #8)
I think https://gitlab.winehq.org/wine/wine/-/merge_requests/4805 mitigates the leak, avoiding the large data allocations.
It is somewhat better: memory consumption is still growing steadily but at a slower rate: 1-2 MB/s and it never decreases. After 15 minutes it reached 1000 MB from the initial 230 MB. Now it took 25 minutes to run out of memory. This kind of memory leak happens only while in the main menu. I tried the tutorial mission and a single player game: memory usage grows and decreases periodically but never comes close to the out-of-memory limit.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #10 from Rémi Bernon rbernon@codeweavers.com --- Mitigation has been committed as 1b753413467b75b0a638ad635127ca5a5e426e7c, can we consider this as fixed?
I'm quite certain that the segment ref leak comes from the game. It's possible it is not supposed to be releasing it but I find it suspicious. It would be interesting to compare to memory usage on Windows and see if there's a small leak there too.
https://bugs.winehq.org/show_bug.cgi?id=56117
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED Fixed by SHA1|68325b385847fd4619fb90b7a64 |1b753413467b75b0a638ad63512 |b8b66b894f134 |7ca5a5e426e7c
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Rémi Bernon from comment #10)
Mitigation has been committed as 1b753413467b75b0a638ad635127ca5a5e426e7c, can we consider this as fixed?
I'm quite certain that the segment ref leak comes from the game. It's possible it is not supposed to be releasing it but I find it suspicious. It would be interesting to compare to memory usage on Windows and see if there's a small leak there too.
I'm not using Windows so can't check whether the game leaks memory while idling in the main menu or not. The GOG.com version has definitely this problem in Wine. Tested again in wine-9.0-rc4-14-g4054795ff19. I'm not against closing as fixed, at least the demo version doesn't have the problem anymore.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #12 from Rémi Bernon rbernon@codeweavers.com --- Tried on Windows myself, the game indeed leeks ~500KB every time the main menu music sequence ends. This is much less frequent than on Wine because the music segment actually plays for a couple of minutes and reloads less frequently.
https://bugs.winehq.org/show_bug.cgi?id=56117
--- Comment #13 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Rémi Bernon from comment #12)
Tried on Windows myself, the game indeed leeks ~500KB every time the main menu music sequence ends. This is much less frequent than on Wine because the music segment actually plays for a couple of minutes and reloads less frequently.
OK, thanks for the explanation and especially for the effort you made fixing this bug.
https://bugs.winehq.org/show_bug.cgi?id=56117
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.0-rc5.
-
WineHQ Bugzilla