ID:110918
 
BYOND Version:480
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 4.0
Applies to:Dream Daemon
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
I happened to be at work when the crash occurred, so I don't have any details as to what was going on at the time. I did, however, get a windows crash dump, so here's the information.

Faulting application name: dreamdaemon.exe, version: 0.0.0.0, time stamp: 0x4d6f4bcf
Faulting module name: byondcore.dll, version: 0.0.0.0, time stamp: 0x4d6f4ba1
Exception code: 0xc0000005
Fault offset: 0x000bc5e7
Faulting process id: 0x1538
Faulting application start time: 0x01cbe507868dcb33
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: 33eaf1b4-5185-11e0-95a7-001e6850cff0


Thanks. I'll run that through on Monday and see if I can get any info on that.
Any information or perhaps related reports?
Dang, this is another proc chain issue like the one Tsfreaks reported. Maybe the same issue, but it's hard to say.

It sounds like either something is causing problems in memory and messing up the stack, or an obscure bug related to sleep() and spawn() is hitting here. If you can provide me with your project source that would be very helpful toward comparing to what Tsfreaks has already discovered. You can email a zip to me at [email protected].
If this is still happening, please try using Microsoft's Application Verifier, attach it to a running Dream Daemon process, and turn on full page heap checking. That was originally a Windows XP tool so hopefully Microsoft makes a version for Windows 7. Basically, full page heap checking should tell us where the memory is getting trashed.
I send you an email with the source. That's about all the time I had to do, been busy.
While it's unrelated to the crash, I did find something you should probably look into:
if(!src.key in Staff)

That needs parentheses; it's actually never hitting because !src.key is 0. Although the way that block is written, it's probably better if it doesn't hit because there is no actual AFK check being done there. I advise just losing it. Also the useless return 0; in fact you have returns in a lot of your spawn() blocks that are doing nothing.

So far I see nothing unusual except that you're doing a very large number of spawn() calls. I suspect that's really just making it easier for the real bug to trigger though, by giving the proc stack more places that can be overwritten.
Much of that code in this source was written like 3 years ago, so it probably is pretty bad. Only the quest stuff is recent. I'm slowing going through and revising.

So far I see nothing unusual except that you're doing a very large number of spawn() calls. I suspect that's really just making it easier for the real bug to trigger though, by giving the proc stack more places that can be overwritten.

Ha you should see my fighter side project. That thing probably has 3x the number of spawn() calls.