View Issue Details

IDProjectCategoryView StatusLast Update
0005107DarkRadiantGUIpublic02.04.2022 05:55
ReporterDragofer Assigned Togreebo  
Status closedResolutionfixed 
OSWindowsOS Version10 
Product Version2.6.0 
Target Version2.13.0Fixed in Version2.13.0 
Summary0005107: 'Change game/project' fails to save if a decent-sized .map was loaded
DescriptionIf I have a sufficiently large .map loaded and then 'Change game/project' to a different FM project, then restart DR, the project setting has reverted back to what it was before.

The bug occurs 100% of the time with Perilous Refuge, but never with the smaller Rats Triumphant or a blank map.
Steps To ReproducePreparation to get you in the same position as a mapper:
1) Download Perilous Refuge to your darkmod/fms folder.
2) Extract peril.pk4 to darkmod/fms/peril. You should now have darkmod/fms/peril/maps/, which DR can access.
3) Open DR and 'Change game/project' to peril.
4) Restart DR to make sure the current project is now peril.

Bug reproduction:
1) Open in DR.
2) 'Change game/project' to a different FM.
3) Restart DR. The current project is still peril.
Additional InformationTested & confirmed in 2.6 and 2.7
TagsNo tags attached.




05.01.2020 13:18

developer   ~0012073

Additional bug when I was isolating the cause of the above bug:
The frequent restarting and loading of my map seems to have broken something in DR's map loading.

First it became increasingly slow to load my map. After a few more restarts&reloads DR started to always crash after changing project.

I've restarted my pc and now DR hangs very long when 'loading textures', with the display in 3D view and orthoview black. Rats Triumphant loads eventually, but I lost patience with Perilous Refuge. Task manager shows DR stuck at 1588mb of RAM when loading Peril's textures.

Never seen this happen with normal use of DR.


05.01.2020 13:33

developer   ~0012074

Additional details to my previous note: I have 8GB of RAM, and when DR stopped responding after changing project I used task manager to end the process. Maybe I've broken my user settings this way.


05.01.2020 17:14

developer   ~0012075

Re: my notes 1 & 2: loaded up some other maps and now:
- DR 2.6 started throwing 'unhandled exception' as soon as opening a map reaches 'loading textures'.
- DR 2.7 is loading fine.

Would you like a ticket for this? The bug resulted from very atypical usage, but I have noticed before that DR starts to slow down after loading several large maps in a row.


06.01.2020 04:25

administrator   ~0012083

The second slowdown issue you described sounds strange, especially after you restarted your computer - it should definitely work fine after a reboot if it was caused by a memory or resource leak.

Can you try to backup your user settings and delete them? When DR settings are clean and your computer is freshly rebooted it really should just work fine, unless OS or hardware are starting to fail on your end.
(Reminds me, a button in DR clearing your user preferences, like a "reset to factory default" is maybe useful too).


06.01.2020 04:27

administrator   ~0012084

On a general note: it's best practice when tracking bugs to not mix them into a single report, for several reasons. Unless the two issues are *very* closely related, each should have its own entry.


06.01.2020 16:19

administrator   ~0012094

Investigating this mod changing problem, it appears the code is deadlocking when the DEF files are re-parsed. The ThreadedDefLoader starts parsing, notifies the EntityNode about the change, the entity refreshes its spawnargs and tries to load a model DEF, which deadlocks because the re-parsing is still in progress. The thread will sit there forever and will even prevent DR from properly shutting down since the EntityClassManager is waiting for any running parsing threads to finish before it shuts down the module.

I haven't ultimately tracked down the cause of the above problem to this deadlock, but to me it might be plausible that things are not properly switched to the new game path setup when threads are not finishing their work.


19.11.2020 03:53

administrator   ~0012989

An a lighter note, the problematic behaviour above has changed into a clean crash in 2.9.0.


25.06.2021 17:11

administrator   ~0014126

I could solve the deadlock problem, the fix is a tad convoluted, but it works.

Related Changesets

DarkRadiant: master 01dbfae2

2020-11-19 05:32:35


Details Diff
0005107: Fix a crash related to project setup changes, due to concurrent calls of SceneGraph::boundsChanged by both the eclass def loader and the material manager realisation thread.
This commit doesn't make it thread-safe, but the call to SceneGraph::boundsChanged is actually unnecessary when just the face shader has been changed.
Affected Issues
mod - radiantcore/brush/Brush.cpp Diff File

DarkRadiant: master 8a5542c3

2021-06-25 10:32:22


Details Diff
0005107: Prevent the renderer getting into the way of DEF parsing (or vice versa). Block screen updates until the DEFs are fully loaded.
Now with this change, the deadlock problem as reported in the issue 5107 is occurring in a resonably large map. This has to be fixed seperately.
Affected Issues
mod - include/ieclass.h Diff File
mod - radiant/ui/mainframe/MainFrame.cpp Diff File
mod - radiant/ui/mainframe/MainFrame.h Diff File
mod - radiantcore/eclass/EClassManager.cpp Diff File
mod - radiantcore/eclass/EClassManager.h Diff File

DarkRadiant: master fd30a033

2021-06-25 12:19:36


Details Diff
0005107: Block the changed signal until parsing is done. When the signal is fired, we must be ready to serve queries to entity classes or model defs without deadlocking in our own ongoing parsing thread.
The change signal is buffered, and should be fired once parsing is done.
Affected Issues
mod - libs/ThreadedDefLoader.h Diff File
mod - radiantcore/eclass/EClassManager.cpp Diff File
mod - radiantcore/eclass/EClassManager.h Diff File
mod - radiantcore/eclass/EntityClass.cpp Diff File
mod - radiantcore/eclass/EntityClass.h Diff File

DarkRadiant: master 3d9251dc

2021-06-25 16:49:17


Details Diff
0005107: Add option to ThreadedDefLoader to invoke a function when the actual worker thread is done (or as good as done). Affected Issues
mod - libs/ThreadedDefLoader.h Diff File
mod - radiantcore/eclass/EClassManager.cpp Diff File
mod - radiantcore/eclass/EClassManager.h Diff File

DarkRadiant: master 5ac84342

2021-06-25 16:57:56


Details Diff
0005107: Simplify a few things. Block callbacks right from the start, since the resolveInheritance and applyColours methods are also triggering change signals. Affected Issues
mod - radiantcore/eclass/EClassManager.cpp Diff File
mod - radiantcore/eclass/EClassManager.h Diff File

Issue History

Date Modified Username Field Change
05.01.2020 13:10 Dragofer New Issue
05.01.2020 13:18 Dragofer Note Added: 0012073
05.01.2020 13:33 Dragofer Note Added: 0012074
05.01.2020 17:00 Dragofer Description Updated
05.01.2020 17:00 Dragofer Additional Information Updated
05.01.2020 17:14 Dragofer Note Added: 0012075
06.01.2020 04:25 greebo Note Added: 0012083
06.01.2020 04:27 greebo Note Added: 0012084
06.01.2020 04:27 greebo Status new => acknowledged
06.01.2020 16:19 greebo Note Added: 0012094
19.11.2020 03:53 greebo Note Added: 0012989
19.11.2020 05:32 greebo Changeset attached => DarkRadiant master 01dbfae2
19.11.2020 05:32 greebo Status acknowledged => confirmed
25.06.2021 05:16 greebo Relationship added related to 0005651
25.06.2021 05:25 greebo Relationship deleted related to 0005651
25.06.2021 17:10 greebo Assigned To => greebo
25.06.2021 17:10 greebo Status confirmed => assigned
25.06.2021 17:10 greebo Target Version => 2.13.0
25.06.2021 17:10 greebo Changeset attached => DarkRadiant master 8a5542c3
25.06.2021 17:10 greebo Changeset attached => DarkRadiant master fd30a033
25.06.2021 17:10 greebo Changeset attached => DarkRadiant master 3d9251dc
25.06.2021 17:10 greebo Changeset attached => DarkRadiant master 5ac84342
25.06.2021 17:11 greebo Status assigned => resolved
25.06.2021 17:11 greebo Resolution open => fixed
25.06.2021 17:11 greebo Fixed in Version => 2.13.0
25.06.2021 17:11 greebo Note Added: 0014126
02.04.2022 05:55 greebo Status resolved => closed