Numbered Steps to Reproduce Problem:
Running one of two(possibly three) maps where the issue exists.
This is a guess, but it seems as though the crashes have to do with explosions, which cause damage to the map in a localized region. Most final logs when crashes do happen are explosions, but this is not always consistent.
Code Snippet (if applicable) to Reproduce Problem:
Not applicable.
Expected Results: No access violation error.
Actual Results:
Faulting application name: dreamdaemon.exe, version: 5.0.512.1466, time stamp: 0x5c9e4325
Faulting module name: byondcore.dll, version: 5.0.512.1466, time stamp: 0x5c9e42ae
Exception code: 0xc0000005
Fault offset: 0x000ff72b
Faulting process id: 0x1168
Faulting application start time: 0x01d4e82581432a52
Faulting application path: C:\byond\bin\dreamdaemon.exe
Faulting module path: C:\byond\bin\byondcore.dll
Faulting application name: dreamdaemon.exe, version: 5.0.512.1466, time stamp: 0x5c9e4325
Faulting module name: byondcore.dll, version: 5.0.512.1466, time stamp: 0x5c9e42ae
Exception code: 0xc0000005
Fault offset: 0x000ff5a8
Faulting process id: 0x1e20
Faulting application start time: 0x01d4e7be48c1a249
Faulting application path: C:\byond\bin\dreamdaemon.exe
Faulting module path: C:\byond\bin\byondcore.dll
ff72b seems to be the most prevalent crash opcode.
Does the problem occur:
Every time? Or how often? Very consistently when the map is run on the public server. Not always triggerable on a private instance.
In other games? N/A
In other user accounts? N/A
On other computers? Possibly?
When does the problem NOT occur? When any other map is run.
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.)
Appeared spontaneously while we ran 512.1462, but did not explicitly appear with it. Has persisted up until 1466. 1464 was also ran for a while, where the issue also existed.
Workarounds:
Do not run effected maps.
An additional note:
This is a list of our maps with their respective line counts, and note of which ones crash. The offending map files will be sent privately.
129 Z.04.Low_Orbit.dmm
32722 Z.02.Admin_Level.dmm
55819 Z.01.Whiskey_Outpost_v2.dmm
60506 Z.01.LV624.dmm
90146 Z.01.BigRed_v2.dmm
113527 Z.01.Ice_Colony_v2.dmm <- Crashes
128893 Z.03.USS_Almayer.dmm
139082 Z.01.Prison_Station_FOP.dmm <- Crashes
208409 Z.01.Desert_Dam.dmm <- Not in rotation enough to report on.
829233 total
Note that all non-Z.01 maps are always compiled and present. Z.01 maps rotate.
To be both more and less specific, it appears the crash is happening when reading a turf's appearance vars. The appearance in question does not, it seems, exist. This should never happen.
In the aforementioned bug, this was happening when appearances got destroyed prematurely, due to references hanging around after a world reboot; those bogus refs being decremented caused valid appearances to die early.
What this case reminds me of is when there were issues with unique turf cell IDs. Past 64K of those (no one map file can pass that limit though), it was sometimes running into problems due to some broken logic. However that too was fixed a while back, and I can't find any evidence of a recent server change that would have caused your issues to appear in 1462. (The most recent server change up to and including 1462 was in 1454.)
It would help to have more info on some of this.
1) What happens during explosions? Are turf appearances often changed?
2) How many turfs, roughly, go through any changes? (A ballpark number rather than a percentage would be great.)
3) Does this issue occur after the subsequent reboot, or during/after the explosion?
4) Are you using visual contents for turfs?
5) Are visual contents on any of the exploded turfs?