DreamDaemon fails to run code properly, SS13

ID:2406749
 
Oct 20 2018, 8:42 pm
(See the best response by Lummox JR.)
Log:
https://pastebin.com/LCCyPM2a
A copy of the code used is available at https://github.com/OracleStation/OracleStation
Problem description:
I'm unable to host a game using Dream Daemon. I'm having the issue on three computers, two windows 10 machines and one VM running vista. There are no issues in the compiler, however Dream Daemon states several errors, which are related to being unable to execute null.Get() or modifying a variable. I'm not exactly the most well versed in DM, but it looks like it's unable to run several functions. Once again, the code can be compiled with 0 errors and 0 warnings which is leaving me very confused about why this is happening. I've tested this with several different SS13 codebases, notably:
https://github.com/OracleStation/OracleStation
https://github.com/tgstation/tgstation
https://github.com/vgstation-coders/vgstation13
which all have the same error. However,
https://github.com/yogstation13/Yogstation-TG
neither the precompiled or a freshly compiled version have the error.
What happens as a result:
Everything simply stops after
Initialized Mapping subsystem within 15.7 seconds!

I've waited for several minutes and nothing has happened.
A reddit thread I posted ( https://www.reddit.com/r/SS13/comments/9ngvjw/ unable_to_host_any_server/ ) has yielded no helpful results and frankly I'm stumped. Nobody else is reporting this error, and the craziest part is that it happens on THREE DIFFERENT COMPUTERS! (as well as several different versions of 512). If anyone knows anything about what exactly is going on here any help would be appreciated.
Oct 22 2018, 9:53 am
Best response
Your compilation doesn't have debug version turned on, which is rather a problem since it's not showing a call stack in the log. According to your log, it's failing somewhere in the Timsort routine, which explains why it's choking somewhere in startup: the subsystems are probably not correctly sorted and in an inconsistent state.

From looking at the only place that error could possibly have come from (turn on debugging!), it appears that for some reason you have a null var that should under no circumstances be null. This is what the code looks like in /tg:

var/datum/sortInstance/SI = GLOB.sortInstance
if(!SI)
    SI = new

SI.L = L
SI.cmp = cmp
SI.associative = associative

There's simply no way for SI to be null there unless something major has gone wrong.

Out of curiosity, is there any chance you're using a weird system locale that might be interfering with the order in which files are compiled?
Oct 22 2018, 5:27 pm
My locale is EN-US.
Debug mode in the compiler was already on, however I turned on "Automatically set FILE_DIR for sub-directories"
Results:
OracleCode: https://pastebin.com/SmRUjtaV (didn't work)
TGCode: https://pastebin.com/ZLjKcDqD (stopped it because it worked and I didn't want to wait)
The debug option was checked, so I don't see why it wouldn't actually debug.
Nov 1 2018, 5:06 am
Don't turn on file dir things, it makes compile time a lot longer and it hasn't been needed for SS13 for at least 2 years now.
Nov 1 2018, 5:32 pm
In response to Laser50
Laser50 wrote:
Don't turn on file dir things, it makes compile time a lot longer and it hasn't been needed for SS13 for at least 2 years now.

...except for the fact that it's the only way TG code actually runs for me
Nov 3 2018, 6:47 pm
It is not needed to run tgcode, (I would know, its my job to run tgcode) to the point that submitting a PR that enables it triggers an automatic rejection.

You messed something up and enabling that was a red Harring. Disable it again, remove all file_URL lines from the .dme file, and try again. I bet it works and you were wrong about what fixed it.