Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001897Zandronum[All Projects] Bugpublic2014-07-24 00:372018-09-30 21:50
Reporterunknownna 
Assigned ToTorr Samaho 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSWindowsOS Version8.1
Product Version1.2 
Target Version3.0Fixed in Version3.0 
Summary0001897: CPU-like lag when picking up items or when flag is taken/dropped/returned after a dozen map changes || Console memory issue
DescriptionI've been playing a lot of CTF and survival lately and have noticed a distinct lag in CTF. After around a dozen map changes, the client starts to lag whenever players join the game, whenever flags are taken/dropped/returned and whenever picking up items. The lag that occurs whenever a flag is taken/dropped/returned and when picking up items is very frustrating to play with.

It is imperative that this issue is looked into is as it prevents you from predicting your own and others movement properly. Note that this isn't some sort of a client-side misprediction at all, it's just some strange CPU-like lag that "piles up" after map changes. It feels like a memory leak, but by looking at the Windows task manager I can see that the memory usage seems to stay the same.

Have a look at the demo in the link below. It starts at MAP01 so you're going to have to use the demo_skiptonextmap command a bit often to get to the later maps. I already notice the lag in MAP11 and MAP16, but it really shows in MAP18 and particularly in MAP21.
Steps To Reproduce1. zandronum -file skulltag_actors_1-1-1.pk3 skulltag_data_126.pk3 veloctfx.wad odaflagx.pk3 skullspree4a.wad hudtimer_v3b.pk3 ctfcaptains_v1b.wad newtextcolours1_170.pk3 connectsound.wad -playdemo 2014.07.21_18.42.10_skulltag_actors_1-1-1pk3.skulltag_data_126pk3.veloctfx.odaflagxpk3.skullspree4a.hudtimer_v3bpk3.ctfcaptains_v1b.newtextcolours1_170pk3.connectsound.cld
2. demo_skiptonextmap to MAP16, MAP18 and MAP21

2014.07.21_18.42.10_skulltag_actors_1-1-1pk3.skulltag_data_126pk3.veloctfx.odaflagxpk3.skullspree4a.hudtimer_v3bpk3.ctfcaptains_v1b.newtextcolours1_170pk3.connectsound.cld
skulltag_actors_1-1-1.pk3
skulltag_data_126.pk3
veloctfx.wad
odaflagx.pk3
skullspree4a.wad
hudtimer_v3b.pk3
ctfcaptains_v1b.wad
newtextcolours1_170.pk3
connectsound.wad
Additional InformationI can always reproduce this issue on the Grandvoid and FUNCRUSHER servers simply by joining a game and playing around 6-10 maps. Every map after that will lag more and more. The only way to fix this is to quit and restart zandronum.exe, simply disconnecting and reconnecting doesn't fix the issue. And it seems that cl_ticsperupdate and cl_unlagged don't have any effect here. I also don't observe this behavior on ZDaemon servers.
Attached Files

- Relationships
related to 0000463resolved Ambient sounds pile up for incoming clients, after map changes and after reconnecting 
related to 0002269closedTorr Samaho Memory leak when running wad with large sectors 

-  Notes
User avatar (0010050)
unknownna (updater)
2014-07-24 00:51

I also only use the software renderer.
User avatar (0012551)
unknownna (updater)
2015-06-06 17:40
edited on: 2015-07-13 09:53

I still notice this behavior in 2.0. It seems to be dependent on how many players there are per map. From what I've observed, if each successive map contains at least around 4 players per team, this undefined lag accumulates after each map. I only managed to work around this by forcing my laptop to run at 100% CPU at all times when playing CTF.

I also notice this issue on DM servers. For some reason it doesn't seem to happen on survival servers.

Edit:

And even setting the CPU to run at 100% at all times didn't fix the issue, it just made it take more map changes for the issue to appear.

User avatar (0012745)
unknownna (updater)
2015-06-17 05:23
edited on: 2015-06-17 14:43

ZDaemon still seems to remain 100% smooth compared to Zandronum after a dozen map changes. I'm beginning to believe there's this serious memory leak or something taking place in Zandronum.

Unfortunately the demo link has died and I don't have the demo on this new laptop of mine, which is a shame since the demo really captured the issue.

Here are my laptop specs:

Windows 8.1 64-bit
8.00 GB RAM
Intel Core i5-5200U CPU @ 2.20GHz
NVIDIA GeForce 820M GPU with 2GB DDR3 VRAM

But since I'm unable to reproduce this issue on my own server I don't really know what to do anymore from here on.

User avatar (0012859)
unknownna (updater)
2015-07-12 01:32
edited on: 2015-07-13 06:34

One thing I observed is that pressing tab to list commands in the console seemingly triggers the lag after being on the server for a while.

Could it be that this issue has something to do with the console accumulating memory when printing messages and potentially not freeing it?

Since messages are printed when players join the game, when items are picked up and when flags are taken/dropped/returned it would make sense that it would lag then.

User avatar (0012895)
unknownna (updater)
2015-07-12 15:48
edited on: 2015-07-13 09:47

Using this binary I was able to induce tons of CPU-like lag when I pressed tab to list commands in the console after 10 minutes or so due to the debug messages that had piled up in the console.

Actually, it already starts to lag after 2 minutes. And it seemingly only lags if cl_capfps is set to 1.

I can confirm that the CPU and memory usage gradually increases when the console is flooded with messages. It's unplayable after 10-15 minutes if cl_capfps is set to 1.

Quote from unknownna
And it seemingly only lags if cl_capfps is set to 1.

After 15 minutes it also lags when cl_capfps is set to 0.

And using the "clear" command in the console doesn't do anything either. It still lags a lot.

Is it possible to have it print the debug messages offline as well? Perhaps it's a (G)ZDoom issue.

Yep, every message that is printed after it has started to lag a lot will cause the client to freeze for a few tics. If you disconnect from the server it also lags offline.

User avatar (0012930)
unknownna (updater)
2015-07-14 13:32
edited on: 2015-07-14 14:31

It seems that (G)ZDoom has added a new console buffer, which should resolve this issue. If you decide to look into this issue, you could probably increase the buffer in the meantime like in ZDaemon until Zandronum catches up with (G)ZDoom.

Playing on a high-intensity CTF server for 2 hours is the equivalent of having your console flooded with debug messages, but with obituaries, pickup messages and flag messages instead.

In particular, this part of the new buffer seems crucial:

//==========================================================================
//
// Delete old content if number of lines gets too large
//
//==========================================================================

void FConsoleBuffer::ResizeBuffer(unsigned newsize)
{
    if (mConsoleText.Size() > newsize)
    {
        unsigned todelete = mConsoleText.Size() - newsize;
        mConsoleText.Delete(0, todelete);
        mBufferWasCleared = true;
    }
}

Now, I don't know how to read code, but apparently this should prevent the console memory from getting too big, right?

Actually, I was able to reproduce this issue in the latest ZDoom SVN build as well. I'll investigate this issue further.

This doesn't happen in ZDaemon because the old lines are simply deleted and cleared from the buffer it seems, thus the gameplay remains 100% smooth there.

User avatar (0012931)
unknownna (updater)
2015-07-14 16:29
edited on: 2015-07-14 16:31

'http://forum.zdoom.org/viewtopic.php?f=2&t=49042 [^]'

If ZDoom won't fix this, we need to add an option that allows us to have the ZDaemon behavior.

User avatar (0012939)
unknownna (updater)
2015-07-14 19:49
edited on: 2015-07-16 11:26

Fixed.

'http://zdoom.org/Changelog/c677dd3/files [^]'
'https://github.com/rheit/zdoom/commit/c677dd37f5ee02d126244f1d15f5854b64edb885 [^]'

Using zdoom-2.8pre-1669-gadd52d4.7z I can confirm that the issue has been resolved. The lag is gone.

Torr, we've got to backport this, we just have to. Please consider backporting this as soon as possible, if possible.

User avatar (0012955)
Edward-san (developer)
2015-07-16 12:29
edited on: 2015-07-16 16:10

Ported the change to the sandbox, here, for testing.

unknownna requested to see this ported into 2.1, so I managed to do it, but required some prior changes. See here.

I still need someone to build the involved changeset ( 7ce4fb6 ).

Here's a build from WaTaKiD:'https://www.dropbox.com/s/b2agi03335hfjk0/zandronum-2.1.1-r150716-1247-7ce4fb6-windows.zip?dl=0 [^]'

User avatar (0012956)
unknownna (updater)
2015-07-16 19:14
edited on: 2015-07-16 19:58

Yeah, that build fixed the issue (thanks, WaTaKiD!). It's now as smooth as ZDaemon. The lag is gone. Great job, Edward-san! There's only one minor side effect of the new behavior:

Quote from unknownna
Quote from Graf Zahl
Quote from unknownna
However, it takes ages for it to generate an error report now if the console was full of stuff before the crash occurred. But I suppose it's fine for most cases though. It'll only take a while if it crashes after hours of play.

Out of curiosity, how long does it take? Several seconds, a minute or even more?

It took around 36 seconds for it to generate the report when crashing after having copy-pasted the command in the OP. That's the equivalence of having played for around 1.5-2 hours on a high-intensity Zandronum CTF server I think.

So if it crashes after playing for a long time it takes a while for it to generate an error report due to how slow the RichEdit control is.

User avatar (0015165)
Torr Samaho (administrator)
2016-07-02 11:20

I transplanted the ZDoom fix to 3.0.
User avatar (0015175)
WaTaKiD (updater)
2016-07-02 15:39

added in 3.0 with:'https://bitbucket.org/Torr_Samaho/zandronum/commits/1835e73c6b2bd91cbbc034826dbcccf34eed1387 [^]'
User avatar (0015754)
unknownna (updater)
2016-10-04 15:12

Hey, I just wanted to let you guys know that this seems to have been fixed now (tested with 3.0-alpha-160814-2010).

One thing though: It would probably be best to have a text somewhere in the error window that says "Generating crash report, please wait." or something like that. I think that to the average user it would look confusing to just see a bunch of commands stream down the window very fast without any further explanation on what's going on. Presumably the user would just close the window before Zandronum got a chance to generate the report.

Anyway, great job, and good luck with further developments!
User avatar (0016723)
Ru5tK1ng (updater)
2017-01-30 01:11

Closing based off of unknownna's testing.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: roman6a unknownna Combinebobnt Razgriz WaTaKiD Mobius Ru5tK1ng FascistCat Daedalus cruduxy Argentum
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2014-07-24 00:37 unknownna New Issue
2014-07-24 00:51 unknownna Note Added: 0010050
2014-07-24 00:56 unknownna Relationship added related to 0000463
2015-06-06 17:40 unknownna Note Added: 0012551
2015-06-06 17:40 unknownna Priority high => normal
2015-06-06 17:40 unknownna Steps to Reproduce Updated View Revisions
2015-06-06 17:41 unknownna Relationship added related to 0002269
2015-06-06 19:25 unknownna Note Edited: 0012551 View Revisions
2015-06-17 05:23 unknownna Note Added: 0012745
2015-06-17 06:11 unknownna Note Edited: 0012745 View Revisions
2015-06-17 14:29 unknownna Note Edited: 0012745 View Revisions
2015-06-17 14:43 unknownna Note Edited: 0012745 View Revisions
2015-07-12 01:32 unknownna Note Added: 0012859
2015-07-12 15:48 unknownna Note Added: 0012895
2015-07-12 15:51 unknownna Note Edited: 0012895 View Revisions
2015-07-12 16:27 unknownna Note Edited: 0012895 View Revisions
2015-07-13 06:34 unknownna Note Edited: 0012859 View Revisions
2015-07-13 09:19 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:23 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:34 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:38 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:39 unknownna Priority normal => high
2015-07-13 09:39 unknownna Status new => confirmed
2015-07-13 09:39 unknownna Summary CPU-like lag when picking up items or when flag is taken/dropped/returned after a dozen map changes in CTF => CPU-like lag when picking up items or when flag is taken/dropped/returned after a dozen map changes || Console memory issue
2015-07-13 09:43 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:47 unknownna Note Edited: 0012895 View Revisions
2015-07-13 09:53 unknownna Note Edited: 0012551 View Revisions
2015-07-13 11:31 unknownna Steps to Reproduce Updated View Revisions
2015-07-14 13:32 unknownna Note Added: 0012930
2015-07-14 13:33 unknownna Status confirmed => feedback
2015-07-14 14:27 unknownna Note Edited: 0012930 View Revisions
2015-07-14 14:31 unknownna Note Edited: 0012930 View Revisions
2015-07-14 16:29 unknownna Note Added: 0012931
2015-07-14 16:29 unknownna Status feedback => new
2015-07-14 16:29 unknownna Status new => acknowledged
2015-07-14 16:29 unknownna Resolution open => waiting for zdoom
2015-07-14 16:31 unknownna Note Edited: 0012931 View Revisions
2015-07-14 19:49 unknownna Note Added: 0012939
2015-07-16 01:42 unknownna Note Edited: 0012939 View Revisions
2015-07-16 07:06 unknownna Note Edited: 0012939 View Revisions
2015-07-16 07:06 unknownna Note Edited: 0012939 View Revisions
2015-07-16 11:18 unknownna Note Edited: 0012939 View Revisions
2015-07-16 11:21 unknownna Priority high => urgent
2015-07-16 11:26 unknownna Note Edited: 0012939 View Revisions
2015-07-16 12:29 Edward-san Note Added: 0012955
2015-07-16 12:50 Edward-san Note Edited: 0012955 View Revisions
2015-07-16 12:51 Edward-san Note Edited: 0012955 View Revisions
2015-07-16 16:10 Edward-san Note Edited: 0012955 View Revisions
2015-07-16 19:14 unknownna Note Added: 0012956
2015-07-16 19:26 unknownna Note Edited: 0012956 View Revisions
2015-07-16 19:58 unknownna Note Edited: 0012956 View Revisions
2015-07-17 12:33 unknownna Assigned To => Edward-san
2015-07-17 12:33 unknownna Status acknowledged => needs review
2015-07-20 13:59 unknownna Note View State: 0012931: private
2015-07-21 12:00 unknownna Target Version => 2.2
2015-08-10 09:26 unknownna Note View State: 0012931: public
2015-12-01 12:26 Edward-san Assigned To Edward-san =>
2016-07-02 11:20 Torr Samaho Note Added: 0015165
2016-07-02 11:20 Torr Samaho Target Version 2.2 => 3.0
2016-07-02 11:21 Torr Samaho Assigned To => Torr Samaho
2016-07-02 11:21 Torr Samaho Status needs review => needs testing
2016-07-02 15:39 WaTaKiD Note Added: 0015175
2016-10-04 15:12 unknownna Note Added: 0015754
2017-01-30 01:11 Ru5tK1ng Note Added: 0016723
2017-01-30 01:11 Ru5tK1ng Status needs testing => resolved
2017-01-30 01:11 Ru5tK1ng Resolution waiting for zdoom => fixed
2017-01-30 01:11 Ru5tK1ng Fixed in Version => 3.0
2018-09-30 21:50 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker