Server Crash while host is online

ID:89509
 
Jan 10 2010, 8:40 am
BYOND Version:462
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 3.5.7
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
I've been able to recreate this issue about 4 times. Basically, when hosting on either Dream Seeker or Dream Daemon, if the host is online and the server reboots, it crashes. I left my server up overnight this evening, and viewed the log when I returned this morning. The log had 2 successful reboots and the server was still up. I logged in just before the next reboot. It rebooted, and the server crashed.
This also caused some player files to bug and they fail to load now, creating a faulty player mob and linking the client to that. When they try to log out of that mob, the game crashes again.
There are no runtime errors and savefile handling has not changed since I created the game. All character and world files were newly created upon hosting.

Numbered Steps to Reproduce Problem:
1. Host game through either Dream Daemon or Dream Seeker.
2. Leave game on (Daemon) without logging in. NO issues during reboot.
3. Login to game and reboot.
4. Server Crashes, bugs player files.

**Skip step 2 and simply reboot if hosted on seeker.**

Code Snippet (if applicable) to Reproduce Problem:
Not applicable


Expected Results:
Proper reboot.

Actual Results:
Server crash.

Does the problem occur:
Every time? Or how often? Everytime so far.
In other games? I've heard rumors, I dunno if its the same cause.
In other user accounts? Yes, with my other host, Legato_frio's account. Same situation.
On other computers? Yes, other host.

When does the problem NOT occur?
When the host is not logged in.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
It seems to be a recent cause. There were no problems of it prior to 461.

Workarounds:
None, outside of no logging in when hosting.

Jan 10 2010, 1:49 pm
Uhh, i've gotten sorta some errors here, different issue, but when I reboot from daemon, when it trys to re-connect, everyone re-connects fine, but me, the host, will fail to get in, and it seems to be relatively new error, i think it happened 2-3 versions or so, it's really annoying, it mostly only likes me to come in then after starting hosting all over again by closing daemon and re-opening it.
Jan 10 2010, 1:50 pm
It is actually just extremely sluggish in working when I do get the error, and eventually it does work, but it's just easier on me when it happens to just popup a new instance of DD.
Jan 10 2010, 5:57 pm
I can't get this to happen in my tests. If you have a project this happens in, you can send me the source files at [email protected] and I'll take a look.

Another possibility is that if you can obtain detailed crash info including the module that crashed and the code offset where it did so, that may be enough for me to trace the bug (though not necessarily to reproduce it).
Jan 11 2010, 8:23 am
Even with the source I was unable to get the crash to occur under multiple scenarios. I think the best way to proceed is to try to get crash details like the module and offset, which I can trace.
Jan 11 2010, 10:28 am (Edited on Jan 11 2010, 10:39 am)
What would be the most efficient way to acquire that data?

Also, looking through the player files, I've noticed that the players who were unable to load their characters correctly seemed to have a .lk file in the files. Could that be the cause? At might, at least, be the cause of the faulty player logins.
Jan 11 2010, 11:34 am
I'm not sure how to get module/offset info on a crash in Windows 7, but generally speaking a crash window will offer you the chance to look at more details.

The .lk file is a lock BYOND puts on the file while it's in use. The .lk file is left behind after the crash because the server doesn't get a chance to delete it. You can safely remove the .lk files without incident, but it doesn't hurt to have them there either.
Jan 11 2010, 3:49 pm
The crash just occurred again. Here are the details from the event log.

For dream daemon:

Faulting application name: dreamdaemon.exe, version: 0.0.0.0, time stamp: 0x4b46dddb
Faulting module name: byondcore.dll, version: 0.0.0.0, time stamp: 0x4b46dd65
Exception code: 0xc0000005
Fault offset: 0x000ba468
Faulting process id: 0x1524
Faulting application start time: 0x01ca91c3dba5bcf0
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: fe7e09a1-fe1b-11de-acb8-001e6850cff0


For dream seeker:

Faulting application name: dreamseeker.exe, version: 1.0.0.1, time stamp: 0x4b46dddf
Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdbdf
Exception code: 0xc00000fd
Fault offset: 0x0000d21e
Faulting process id: 0x132c
Faulting application start time: 0x01ca922a984092dd
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamseeker.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 5b7f0714-fe1e-11de-acb8-001e6850cff0

I don't know if that tells you anything.
Jan 12 2010, 4:36 am
That should help a lot, thanks. So I can confirm I have the right one, can you tell me which exact build of 462 you're using, including the minor build number?
Jan 12 2010, 5:43 am
If my trace is right you're using build 462.1055, not 462.1056, so I do recommend an upgrade. It won't solve the problem though.

The issue appears to be buried deep in the way our procs are handled and is directly related to the erasure of some savefile vars. This will not be an easy fix, particularly since it seems to only come up in certain cases that will be hard to catch. (On the plus side, this does not appear to be a new issue to 462.) I see in your source you have a var/tmp/savefile setup for every client. For some reason it appears that having these vars open is freaking out the server during the reboot, so as a workaround my recommendation would be to avoid keeping savefile vars around when they're not needed, and only open them on an as-needed basis.