Descriptive Problem Summary:
I had to revert our 512 testing server to 512.1395 from 512.1398 because of an issue with repeated lockups and/or crashes near world.reboot() time that also happened in 512.1397.
A coder said they once had the same issue in a project that involved a lot of sleeps.
The timing of the bug would make sense. I didn't test 1396 thou because of the issues.
Once I have more time I'll try to get this down to a test case and/or analyze our logs to make sure they always happened near world.Reboot().
One other hint is it seemed to happen shortly after updating the game code. the coder who had the issue said it happened when they had updated the code to their testing project and restarted.
Since this involves live swapping dmbs (something the ref for world.Reboot() says is supported), it could be relating to references that are sticking around becoming invalid.
ID:2324176
Dec 12 2017, 1:37 am
|
|||||||||||||
Resolved
| |||||||||||||
If you can get me crash details for those reboots, that would be a very very big help.
Logically I would expect the proc scheduler change to be the cause of this, but I'd like to be able to narrow down how and why it's happening. |
this is from my own computer. (running 1398)
I had stopped the world, made an edit, and than restarted the started Faulting application name: dreamdaemon.exe, version: 5.0.512.1398, time stamp: 0x5a2aff06 Faulting module name: ntdll.dll, version: 6.1.7601.23403, time stamp: 0x56f5847f Exception code: 0xc0000005 Fault offset: 0x0002e064 |
Got it to happen with vs attached
ntdll.dll!_RtlFreeHeap@12() + 0x3f bytes kernel32.dll!_HeapFree@12() + 0x14 bytes dreamdaemon.exe C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe N/A N/A Binary was not built with debug information. 1 5.00.512.1398 12/8/2017 13:07 010A0000-010DD000 [4296] dreamdaemon.exe: Native |
And have a reproduction project
world run that and you'll get a crash within a few seconds |
Thanks for that! That test project was the smoking gun I needed.
Looks like multiple reboots triggered the problem, and it was because a pointer used for the new proc queue was being freed but never reset to null. Reallocs to the pointer after that caused the crash. |
This occurs with my full sized game however I did get it to happen once or twice with a very small scale test server (20x20 map, 2 code files)
To note, I've only recently tested this due to reports my game is going down after reboots and I don't currently have any logs.