View Issue Details

IDProjectCategoryView StatusLast Update
0005107DarkRadiantGUIpublic19.11.2020 05:32
ReporterDragofer Assigned To 
Status confirmedResolutionopen 
OSWindowsOS Version10 
Product Version2.6.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.

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

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 View Revisions
05.01.2020 17:00 Dragofer Additional Information Updated View Revisions
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