View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005107||DarkRadiant||GUI||public||05.01.2020 13:10||19.11.2020 05:32|
|Summary||0005107: 'Change game/project' fails to save if a decent-sized .map was loaded|
|Description||If 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 Reproduce||Preparation 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/peril.map, 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.
1) Open peril.map in DR.
2) 'Change game/project' to a different FM.
3) Restart DR. The current project is still peril.
|Additional Information||Tested & confirmed in 2.6 and 2.7|
|Tags||No tags attached.|
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.
|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.|
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.
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).
|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.|
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.
|An a lighter note, the problematic behaviour above has changed into a clean crash in 2.9.0.|
DarkRadiant: master 01dbfae2
2020-11-19 05:32:35Details 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.
|mod - radiantcore/brush/Brush.cpp||Diff File|
|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|