Dream Daemon closes during an "in world" loop

ID:2392568
 
Aug 17 2018, 9:14 am
Resolved
An issue was discovered in the handling of the unique map cell list, in which the NONE value could be assigned incorrectly to a turf.
BYOND Version:512.1446
Operating System:Windows 10 Pro 64-bit
Web Browser:N/A
Applies to:Dream Daemon
Status: Resolved (512.1447)
This issue has been resolved.
Descriptive Problem Summary:
Dream Daemon closes unexpectedly, presumably because of an "in world" for loop.
The following link is a zip containing the baystation12 source code, modified so that it calls "world.Reboot()" if it managed to not crash after initializing all subsystems.
https://github.com/DamianX/Baystation12/archive/Crash.zip

Numbered Steps to Reproduce Problem:
- Download the zip, extract, compile the project.
- Open DD, run it.
- The game will automatically reboot until the problem manifests itself.

To be clear: the issue is present in the original source code, even without this auto-reboot modification. The modification is only to make it easier to reproduce.

Expected Results:
The game shouldn't crash.

Actual Results:
The game might crash.

Does the problem occur:
Every time? Or how often? Seems to happen randomly.
In other games? I've only experienced this issue while working on baystation.
In other user accounts? N/A
On other computers? Other people have verified this happens.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? I couldn't reproduce the problem on 511.1385 but due to the random nature of it, I could have simply been lucky.

Aug 17 2018, 1:57 pm
Do you have details from the crash? That would be helpful.

Also, were you monitoring memory usage at all during this process? I'm curious if the rapid-fire reboots were responsible for a leak that got out of control.
Aug 17 2018, 1:57 pm
I'm not sure how to get them. DD just closes.
Aug 17 2018, 3:19 pm
Windows event viewer. If DD is really crashing then it's leaving evidence behind. If it's closing outright there may well be some specific code in the game causing that.
Aug 18 2018, 2:44 am (Edited on Aug 18 2018, 3:37 am)
 
Faulting application name: dreamdaemon.exe, version: 5.0.512.1446, time stamp: 0x5b6de4f8
Faulting module name: byondcore.dll, version: 5.0.512.1446, time stamp: 0x5b6de484
Exception code: 0xc0000005
Fault offset: 0x000fa60b
Faulting process ID: 0x2838
Faulting application start time: 0x01d436cdbe3912ec
Faulting application path: D:\Games\byond-512-1446\bin\dreamdaemon.exe
Faulting module path: D:\Games\byond-512-1446\bin\byondcore.dll
Report ID: cc8b5fe9-5ebe-4f3a-a447-8010af21cacc
Faulting package full name:
Faulting package-relative application ID:


Edit: memory usage seems normal.
https://i.imgur.com/PzNmkW7.png

Let me know if there's anything else that can help.
Aug 18 2018, 2:32 pm (Edited on Aug 18 2018, 2:41 pm)
Okay, it looks like this is a repeat of a bug that's been reported on and off for SS13 where sometimes it's trying to access an appearance var of a turf, and for whatever reason the turf appearance is null. That should never, ever happen.

I suspect something internal is passing a point where it triggers this bug, and the repeated reboots are getting it there faster. But I have no idea what can lead to this. The code for handling unique cells should be bulletproof at this point.

[edit]
Hmm, I found something that might explain this after all. Sometimes it takes looking at the same piece of code dozens of times, apparently.
Aug 19 2018, 11:05 pm
Lummox JR resolved issue with message:
An issue was discovered in the handling of the unique map cell list, in which the NONE value could be assigned incorrectly to a turf.