Dark radiant crash on update entities on every change

[OGDA]

Hello,

I get a dark radiant crash every time I try to use

Connection > Update entities on every change

 

I do the following steps:

1. Start TDM, load map with console command "map anol"

2. Enter in console "com_automation 1", windows firewall request was accepted the first time (no other firewall is running)

3. Start dark radiant and load corresponding map fms/anol/maps/anol.map

4. Activate "Game position follows dark radiant camera" > camera synchronisation is working

5. Change an entity and use Connection > Update entities now > working without problems

6. Activate Connection > Update entities on every change

7. As soon as any entity is moved, dark radiant crashes by directly closing without giving an error on the desktop

 

When this happens, TDM prints the following in the console:

HotReload: SUCCESS
ERROR: idTCP::Read: WSAECONNRESET
Automation lost connection

 

I'm using TDM 2.09/64 #9108 and
Dark radiant 2.11.0 x64 Build date Jan 29 2021 13:59:57

Please help!
If you need any more info (logfiles or anything like that) please tell me where to find it.

 

Edited February 28, 2021 by OGDA

[stgatilov]

I'll probably ask for @greebo's help here.

I think what would be helpful here is crashdump of DarkRadiant.

[OGDA]

@greebo

Here's the Dump for dark radiant after the error has occured:
https://das-kartell.org/files/darkradiant_error/DarkRadiant.zip

I've installed Visual Studio. When I click Debug in the error message popup, it tells me:
Unhandled exception at 0x00007FF9EFB1286E (ucrtbase.dll) in DarkRadiant.exe: Fatal program exit requested.

[greebo]

Thanks for the dump. I can't look into this right now, but if you could open an entry on the bugtracker the chances of me forgetting are smaller.

[stgatilov]

4 hours ago, OGDA said:

I've installed Visual Studio. When I click Debug in the error message popup, it tells me:
Unhandled exception at 0x00007FF9EFB1286E (ucrtbase.dll) in DarkRadiant.exe: Fatal program exit requested.

Installed Visual Studio, really?!
Are you a C++ programmer by any chance?

Unfortunately, some more stuff is needed to analyze the dump: PDB file for the exact DarkRadiant version, and source code for that version.

[OGDA]

While I've programmed several C++ programs, I'm not very used to Visual Studio debugging.

I've downloaded the source code already over github. Where do I get the PDB-Files for dark radiant versions?
(the specific version is Dark radiant 2.11.0 x64 Build date Jan 29 2021 13:59:57 )

In the wiki I only found the PDB location for TDM itself, but not for dark radiant.

[greebo]

You can find the PDBs right next to the release builds on github: https://github.com/codereader/DarkRadiant/releases/download/2.11.0/darkradiant-2.11.0-x64.pdb.7z

[OGDA]

I was able to compile the source code and then run dark radiant.

The error happens with the downloaded version and with the self compiled version.

 

Is this the relevant info?
If yes, I'll create a bug ticket.

If any additional information is needed, please let me know.

 

Dump file of the crash with the self compiled version:
https://das-kartell.org/files/darkradiant_error/DarkRadiant_2.zip

 

 

Edited March 1, 2021 by OGDA

[greebo]

Yes, it's relevant. Thanks for going this far!

[OGDA]

Bug Ticket created!

I got the ID .... (drums and cheers):     5555

xD

https://bugs.thedarkmod.com/view.php?id=5555

[greebo]

Thanks for the detailed report!

[OGDA]

Thank you all for your help!

[greebo]

Thanks for the reminder, I had a look at the crashdump you uploaded. This seems to be a double-entering problem, the map diff method is entered twice through the idle callback. Due to the whole progress UI handling the map saving is taking longer than 123ms and the timer to trigger the map save is fired another time before the first one is finished. Down the line this causes a lock_guard to throw exceptions since it tries to lock a mutex it already holds.

The MapExporter class has an option to switch off the progress UI when saving, which is likely to solve the problem. Still, the timer callback should probably be protected against double-entering too.

[stgatilov]

Yes, recursive "think" should be skipped.