Numbered Steps to Reproduce Problem: I couldn't say, unfortunately.
Code Snippet (if applicable) to Reproduce Problem: Not applicable.
Expected Results: Server not to crash.
Actual Results: Server does crash.
Does the problem occur:
Every time? Or how often? So far just this once. Server is running on the beta build.
In other games? Not that I've experienced but probably.
In other user accounts? Not really applicable.
On other computers? Possibly?
When does the problem NOT occur? Older versions perhaps? I could try downgrading the server version and see if that fixes anything.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? It definitely hasn't happened before, but I've hosted on this version of BYOND a couple times before already.
Crash Report:
UG: Crashing due to an illegal operation!
Backtrace for BYOND 511.1364 on Linux:
Generated at Sun Dec 4 16:30:32 2016
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xb7265000, 0x0], 0x29e8c0
[0xb77bb000, 0xb77bb40c], [0xb77bb000, 0xb77bb40c]
libbyond.so [0xb7265000, 0x0], 0x29e8c0
libbyond.so [0xb7265000, 0x0], 0x2a0db4
libbyond.so [0xb7265000, 0x0], 0x217f7d
libbyond.so [0xb7265000, 0x0], 0x21e169
libbyond.so [0xb7265000, 0x0], 0x2227ac
libbyond.so 0x33b2a0, 0x33b3ba
libbyond.so 0x305060, 0x305262
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x19020, 0x19113 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]
Recent proc calls:
/atom/New
/turf/grass/New
/dmm_suite/preloader/New
/atom/New
/obj/markers/rain_spawn/New
/dmm_suite/preloader/New
/dmm_suite/proc/parse_grid
/dmm_suite/preloader/New
/atom/New
/turf/grass/New
/dmm_suite/preloader/New
/atom/New
/obj/markers/rain_spawn/New
/dmm_suite/preloader/New
/dmm_suite/proc/parse_grid
/dmm_suite/preloader/New
I have a core file if you need that, too.
The crash is happening inside of mapped_areas.Add(), which keeps track of areas each client knows about, and it's happening specifically within MapObject::Copy(). There's a bit of code that looks up the icon that goes with an appearance and tries to look up the number of directions it has. Apparently this is breaking down in AppearanceGet_icon(), which is a macro that simply grabs the appearance without a validity check and gets its icon.
Simply put, what's happening here should never happen, because basically what's causing the crash is that the area has a null appearance--which should not be possible. And in fact this means the area's new appearance is null.
Fortunately, the dirs-in-icon check appears to be very very moot now, as the meat of it has actually been out of production for a long time, so I think I can simply remove this code entirely which should obviate the bug--at least in this spot. The bigger question of how the area could be assigned a null appearance is still open.