MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002269 | Zandronum | [All Projects] Bug | public | 2015-05-28 15:24 | 2018-09-30 21:43 |
|
| Reporter | Hypnotoad | |
| Assigned To | Torr Samaho | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 |
| Product Version | 2.0 | |
| Target Version | 3.0 | Fixed in Version | 3.0 | |
|
| Summary | 0002269: Memory leak when running wad with large sectors |
| Description | Tribeam has alerted me to the fact that Zandronum can use a huge amount of memory when running a wad with very big sectors. In his case a wad was using up to 1.6 GB of memory. The issue is not fixed when setting sv_disallowbots to 1. The issue does not happen in ZDoom. Tribeam has provided this example wad:
'https://dl.dropboxusercontent.com/u/49758621/Map01Tri.wad [^]'
Map01, which is just a large empty sector, uses over 500mb of memory for me. |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | 0001897 | closed | Torr Samaho | CPU-like lag when picking up items or when flag is taken/dropped/returned after a dozen map changes || Console memory issue |
|
| Attached Files |  Map01Tri.wad (5,036) 2016-06-26 20:27
/tracker/file_download.php?file_id=1842&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2015-05-28 15:24 | Hypnotoad | New Issue | |
| 2015-05-28 17:58 | Torr Samaho | Note Added: 0012439 | |
| 2015-05-28 18:08 | WaTaKiD | Note Added: 0012440 | |
| 2015-05-28 21:13 | ibm5155 | Note Added: 0012444 | |
| 2015-06-06 17:41 | unknownna | Note Added: 0012552 | |
| 2015-06-06 17:41 | unknownna | Relationship added | related to 0001897 |
| 2015-06-09 09:08 | unknownna | Note Added: 0012610 | |
| 2015-06-09 09:08 | unknownna | Status | new => confirmed |
| 2015-06-09 09:10 | unknownna | Note Edited: 0012610 | bug_revision_view_page.php?bugnote_id=12610#r7328 |
| 2015-06-09 09:11 | unknownna | Note Edited: 0012610 | bug_revision_view_page.php?bugnote_id=12610#r7329 |
| 2015-06-09 12:23 | Edward-san | Note Added: 0012611 | |
| 2015-06-09 12:28 | Edward-san | Note Edited: 0012611 | bug_revision_view_page.php?bugnote_id=12611#r7331 |
| 2015-06-09 12:28 | Dusk | Note Added: 0012612 | |
| 2015-06-09 12:42 | Edward-san | Note Added: 0012613 | |
| 2015-06-09 12:42 | Edward-san | Note Edited: 0012613 | bug_revision_view_page.php?bugnote_id=12613#r7333 |
| 2015-06-09 12:48 | Edward-san | Note Edited: 0012613 | bug_revision_view_page.php?bugnote_id=12613#r7334 |
| 2015-06-09 12:48 | Edward-san | Note Edited: 0012613 | bug_revision_view_page.php?bugnote_id=12613#r7335 |
| 2015-06-09 12:50 | Edward-san | Note Edited: 0012613 | bug_revision_view_page.php?bugnote_id=12613#r7336 |
| 2015-06-09 13:05 | Dusk | Note Added: 0012614 | |
| 2015-06-09 13:55 | Edward-san | Note Added: 0012615 | |
| 2016-06-26 20:25 | Torr Samaho | Note Added: 0015136 | |
| 2016-06-26 20:27 | WaTaKiD | File Added: Map01Tri.wad | |
| 2016-10-19 11:30 | unknownna | Note Added: 0016058 | |
| 2017-04-02 20:28 | Torr Samaho | Note Added: 0017080 | |
| 2017-04-02 20:28 | Torr Samaho | Assigned To | => Torr Samaho |
| 2017-04-02 20:28 | Torr Samaho | Status | confirmed => needs testing |
| 2017-06-28 01:35 | Ru5tK1ng | Note Added: 0017946 | |
| 2017-06-28 01:35 | Ru5tK1ng | Status | needs testing => resolved |
| 2017-06-28 01:35 | Ru5tK1ng | Resolution | open => fixed |
| 2017-06-28 01:35 | Ru5tK1ng | Fixed in Version | => 3.0 |
| 2017-06-28 01:35 | Ru5tK1ng | Target Version | => 3.0 |
| 2018-09-30 21:43 | Blzut3 | Status | resolved => closed |
|
Notes |
|
|
|
|
How do Zandronum 3.0 and GZDoom 1.8 handle this? |
|
|
|
|
|
zan 3.0 is taking over 500mb for me, gzdoom 1.8 only about 60 |
|
|
|
|
|
|
|
|
|
If this is true (didn't test yet), I think it might be related to the issue I reported earlier. |
|
|
|
(0012610)
|
|
unknownna
|
2015-06-09 09:08
(edited on: 2015-06-09 09:11) |
|
The memory issue only happens on the server-end or when playing offline it seems, but the Zandronum client still uses more memory than GZDoom.
GZDoom r900 : 17.4 MB
Zandronum 2.0 Offline : 489.0 MB
Zandronum 2.0 Online Server : 472.8 MB
Zandronum 2.0 Online Client : 28.2 MB
GZDoom 1.8.02 : 18.0 MB
|
|
|
|
(0012611)
|
|
Edward-san
|
2015-06-09 12:23
(edited on: 2015-06-09 12:28) |
|
Breakpoint 1, ASTAR_BuildNodes ()
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/astar.cpp:155
155 g_aMasterNodeList = new ASTARNODE_t[g_lNodeListSize];
(gdb) p g_lNodeListSize * sizeof(ASTARNODE_t)
$1 = 631296000
(gdb) p g_lNodeListSize
$2 = 144000
(gdb) p sizeof(ASTARNODE_t)
$3 = 4384
So yeah.
|
|
|
|
(0012612)
|
|
Dusk
|
|
2015-06-09 12:28
|
|
|
So the problem here is that the bot nodes get generated even if sv_disallowbots is true? |
|
|
|
(0012613)
|
|
Edward-san
|
2015-06-09 12:42
(edited on: 2015-06-09 12:50) |
|
Yeah, something is wrong with this:
// [BC] Also, build the node list for the bot pathing module.
if (( NETWORK_GetState( ) != NETSTATE_CLIENT ) &&
( CLIENTDEMO_IsPlaying( ) == false ) &&
(( level.flags2 & LEVEL2_NOBOTNODES ) == false ) &&
(( NETWORK_GetState( ) != NETSTATE_SERVER ) || ( sv_disallowbots == false )))
{
ASTAR_BuildNodes( );
}
[edit] the cvar works and doesn't eat much memory for the server, it doesn't work offline (both in single player and multiplayer).
|
|
|
|
(0012614)
|
|
Dusk
|
|
2015-06-09 13:05
|
|
|
It seems Carn specifically intended for bot nodes to always be built offline. So there is no bug here. |
|
|
|
|
|
I don't like the offline behavior. If I don't want to use the bots, there's no way I'd allow the nodes to build and consume memory. |
|
|
|
|
|
Can somebody reupload the wad? |
|
|
|
|
I was just affected by this issue yesterday while testing 3.0 with Complex Doom/LCA on a survival server with some bots in h_phobia.wad: MAP06
With 4 bots present in MAP06, the server gradually starts to choke on its own memory or something and the non-spectating clients then start to jitter around tremendously, even with a local connection to the server. If I remove one bot, the issue seemingly goes away. After a while, the server console gradually becomes unresponsive and you can then only control the server through RCON commands. If you then remove enough bots after it has become too unresponsive, all the commands that you entered into the server console itself floods it and activate at once.
At first I thought it was some major regression in 3.0 and was about to make a new bug report, but then I remembered this particular issue, as the server uses a lot more memory (14.5 MB vs 233+ MB) on that particular map when sv_disallowbots is 0. |
|
|
|
|
|
Memory for the bot nodes should now only be allocated if necessary. |
|
|
|
|
|
Tested the fix and the memory is much better than in 2.0 when not using bots in the example wad. |
|