Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5522 closed defect (fixed)

Grid.h memory leak

Reported by: Minohaka Owned by: wraitii
Priority: Release Blocker Milestone: Alpha 24
Component: Simulation Keywords: regression
Cc: Patch:

Description

Assertion failed: "0 && (L"FYI: WARN_IF_FALSE reports that a function failed. Feel free to ignore or suppress this warning.")"

Location: wdbg_sym.cpp:91 (InitDbghelp)

Attachments (4)

crashlog.txt (22.6 KB ) - added by Minohaka 5 years ago.
crashlog.dmp (126.1 KB ) - added by Minohaka 5 years ago.
commands.txt (186.6 KB ) - added by Minohaka 5 years ago.
commands.2.txt (612.8 KB ) - added by elexis 5 years ago.
r22537 replay with 50 cav units running in circles, memory use > 1.3GB

Download all attachments as: .zip

Change History (12)

by Minohaka, 5 years ago

Attachment: crashlog.txt added

by Minohaka, 5 years ago

Attachment: crashlog.dmp added

by Minohaka, 5 years ago

Attachment: commands.txt added

comment:1 by elexis, 5 years ago

I guess that's following the discussion in http://irclogs.wildfiregames.com/2019-07/2019-07-19-QuakeNet-%230ad-dev.log

It speaks of

errno = 12 (Not enough memory)

But that is probably it failing to use your memory.

Memory : 32768 MiB; 21627 MiB free

You had also posted some GL errors.

One needs to be able to reproduce the issue, so one needs to know which steps you performed that led to this crash, and ideally find a way to perform the same steps to reliably get the same result; then one can inspect and possibly fix it.

We mentioned to test that using replaymode. If it's 4v4 * 150 on a normal mapsize, that certainly ought not to crash or fail due to OOM.

comment:2 by Minohaka, 5 years ago

I'm pretty sure there's some memory leak somewhere. I often play the same scenario in the A23 version and I never get OOM problems. Furthermore I was playing the same scenario 4*200 on linux the game reached 22GB of ram at one point. I don't think that's normal regardless of the 4K monitor and many units on the map or maybe I'm wrong. Sorry I don't have more specific insight on the matter

comment:3 by elexis, 5 years ago

Milestone: BacklogAlpha 24
Priority: Should HaveRelease Blocker

comment:4 by elexis, 5 years ago

Component: Core engineSimulation
Summary: Assertion failed: "0 && (L"FYI: WARN_IF_FALSE reports that a function failed. Feel free to ignore or suppress this warning.")"Some memory leak

Please always post the revision you're running the replay with, it wasn't obvious that it is alpha 24 and that you reported a huge memory leak regression (at least assuming that the report is valid).

The replay is done with 3 AIs, so one could easily blame that.

When doing the a24 testgame in #5529 without AIs, my computer froze because of out-of-memory.

I did a testgame with 50 cavalry units, no AIs and letting the cavalry run in circles (without increasing much map vision), and the game increased by 100mb ram usage every 45s or so.

So it seems like there is some unitmotion/pathfinder leak?

by elexis, 5 years ago

Attachment: commands.2.txt added

r22537 replay with 50 cav units running in circles, memory use > 1.3GB

comment:5 by wraitii, 5 years ago

See https://code.wildfiregames.com/rP22511#inline-3747

Indeed a release blocker, indeed in the pathfinder (specifically the long pathfinder).

See D2121 for a possible fix.

Last edited 5 years ago by wraitii (previous) (diff)

comment:6 by wraitii, 5 years ago

Owner: set to wraitii
Resolution: fixed
Status: newclosed

In 22545:

Fix memory leak introduced by rP22511 in SparseGrid

Following rP22511, SparseGrid::Reset() replaces the value of m_Data (a C-style dynamically sized array) with a new value-initialised array, by using the new operator. Previous code simply did a memset.
This means that when m_Data was not null, it leaked memory as the previous array was not deleted.

SparseGrid::Reset is called when destroying the sparse grid, and a SparseGrid is used by the long pathfinder when computing JPS paths. As that is called rather often, it resulted in a relatively serious memory leak that could make very long games use several GB of memory.

This fixes the leak by using placement new, which re-uses the memory, effectively doing the same as the previously existing memset.

Profiling by historic_bruno and elexis showed that performance from value-initialising with placement new was at worst similar to memset, and testing shows this was compiled in a memset call in several cases anyways.

Reviewed By: elexis

Fixes #5522

Differential Revision: https://code.wildfiregames.com/D2121

comment:7 by elexis, 5 years ago

Summary: Some memory leakGrid.h memory leak

comment:8 by elexis, 5 years ago

Keywords: regression added
Note: See TracTickets for help on using tickets.