Memory leak bug report

[Jimmy Taker]

Hi,

First let me say, DxWnd is AMAZING. It is stuff like this that made me fall in love with programming so many years ago.

It is not yet perfect though. A memory leak occurs which leads to an OOM crash after awhile.

The game is GOG Patrician 3. I used the .dxw from here:
https://sourceforge.net/p/dxwnd/discussion/general/thread/fda6dcc63c/

I used the current DxWnd version.

To reproduce:

1. Start the game and find its process in Windows Task manager.
2. Start a game.
3. Use the right-most button under the mini-map (the settings wheel) to access the settings screen.
4. Now watch the Task manager while clicking "Cancel" so that the game resumes -> The game allocates about 10 MB of additional memory every time the settings screen exits. This memory is never released and eventually the game runs OOM.

The game changes resolution in the game world and menu. So each time the settings is opened and closed the resolution changes. Looks to me like DxWnd allocates additional memory for each of these resolution changes, but never releases said memory. Maybe there are not many games that change resolution in game so this was never noticed before.

I am pretty confident you will easily find and solve this issue.

On a side note - if I may suggest a new feature/setting. I think it would be nice if DxWnd could implement resolution change before launching a game.

Take Patrician for example. The highest resolution it supports (without patching) is 1280x1024. I find it best if run in a modal window that covers the whole screen. This looks best if the screen is set to the game's resolution. It looks just like when running the game natively, however you can keep using secondary monitors. It would be cool if DxWnd could change a monitors resolution to 1280x1024 before running the game and then back to native resolution after exiting the game.

You could call the option "Emulate full screen" :).

Cheers!

JT

[gho]

I saw the problem, thank you very much for notifying it.
The problem is evident, though maybe in different intensity, with all the working renderers, which seems to point on some general DxWnd parts (like the handling of different resolutions) though in theory it could also be a game bug.
Usually this type of problems are not so easy to track and fix, so be sure I'll try hard to do my best, though results may come not so soon or (in case of the game bug) maybe never.

[gho]

The hunt begins.
This extract from the logs shows what happens to the ddraw surfaces used in the gaming session when repeatedly entering and exiting the settings menu.

CreateSurface: created DDSPrim=0x3cd2600 DDSBack=0x3cd26c0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3cd28a0
CreateSurface: created DDSPrim=0x3d70230 DDSBack=0x3d70290 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70350
CreateSurface: created DDSPrim=0x3d6ff90 DDSBack=0x3d6ffb0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70310
CreateSurface: created DDSPrim=0x3d70110 DDSBack=0x3d6ff90 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d6ff70
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d700d0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d702f0
CreateSurface: created DDSPrim=0x3d701b0 DDSBack=0x3d706f0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70110
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d70710 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d706d0
CreateSurface: created DDSPrim=0x3d701b0 DDSBack=0x3d70670 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70610
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d70410 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70690
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d705d0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d706b0
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d705f0 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70510
CreateSurface: created DDSPrim=0x3d701b0 DDSBack=0x3d70430 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d705b0
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d70450 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70390
CreateSurface: created DDSPrim=0x3d70090 DDSBack=0x3d70b50 DDSEmu_Prim=0x3cd25c0 DDSEmu_Back=0x3d70550

Though this proves nothing, it seems that the primary surfaces are correctly recycled (the new surface handle gets the same id of the previous handle) while this doesn't happen to the backbuffers. Maybe the game doesn't properly close the backbuffer surface. It is a possible theory.

[gho]

What a lucky guess! In effect, the problem was just that.
The game releases the primary surface to build a new one every time that it enters or exits the setup screen. In doing that, the game rely on the fact that ddraw automatically closes and releases the unreferenced backbuffers, but this doesn't happen for the DxWnd emulated backbuffer that remains active and swallows memory.
This release seems to fix the problem perfectly. I tested it with "Patrician III" and it works like a charm, but hopefully it won't introduce regressions in other games. We'll keep an eye on that!

P.s. the fix was in the middle of the development of the new release, if you want to test it maybe you will find some weird new GUI. In that case, just ask, we'll support you.

[gho]

BEWARE: the fix in v2.05.83 fixes the memory leakage problem, but crashes some games because some service surfaces get destroyed too early. I'm fixing this logic again in v2.05.84. Stay tuned ...