View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0029663||Runner||Surfaces||Public||2018-06-14 07:30||2019-01-04 17:25|
|Reporter||Mark Alexander||Assigned To||Alan Savage|
|Priority||High||Severity||B - Major||Reproducibility||100%|
|Target Version||2.2.1||Fixed in Version||2.2.1|
|Summary||0029663: Surfaces: Creating and destroying surfaces appears to have a memory leak|
|Description||If you run the attached test program using the debugger and let it run, you can see that the memory use just keeps going up and up and up... suggesting a memory leak when using surfaces.|
|Steps To Reproduce||Import attached project.|
Run in debug mode.
Leave it running for a few minutes.
Observe that the debug graph shows a constant uptick in memory use over time.
|Tags||No tags attached.|
|1.4 Found In|
|2.x Runtime Found In||126.96.36.199|
|2.x Runtime Verified In||188.8.131.528|
Surface Test.yyz (20,001 bytes)
-leak appears to be internal to D3D - runner memory/bucket allocations are freed correctly, and vs graphics debugger confirms that d3d objects are also released. The issue only presents on repeatedly creating and destroying surface of a unique size every time; memory is stable when creating and freeing surfaces of the same size or from a limited set of sizes. The example is contrived and allocation pattern is highly unlikely to occur in practice (and there seems to be nothing we can do about it any case).
Above commit sha refers to a fix for a minor memory leak from debug tags allocated when debugging and certain functions are called