Emptying vis_locs on deletion of an object caused crashes in some cases, mostly during world shutdown.
BYOND Version:512.142x
Operating System:Windows 10 Pro
Web Browser:Firefox 60.0
Applies to:Dream Daemon
Status: Resolved (512.1425)

This issue has been resolved.
Descriptive Problem Summary:
Attempting to world/Reboot or world/Del (which is what I assume the stop button in DreamDaemon does), DreamDaemon immediately crashes.

Easy to test, just checkout and compile it. Start DreamDaemon (no need to connect), and wait a few seconds until the timer starts counting up, then click Stop. DD will immediately crash.

This also occurs when calling world/Reboot().

Numbered Steps to Reproduce Problem:
Compile code (linked above)
Start in DreamDaemon
Attempt to stop DreamDaemon

Code Snippet (if applicable) to Reproduce Problem: N/A

Expected Results: Normal server shutdown or reboot.

Actual Results: DreamDaemon immediately crashes.

Does the problem occur:
Every time? Or how often? Every time
In other games? No
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?
I have a commit in our Git repository that it doesn't occur prior to, but it's a merge commit, and as such is just a bunch of other commits. A developer is trying to bisect the commit history to find when it started, but meanwhile it's obviously a Byond bug, so I'll report it here.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Occurs in at least all the 512s I've tested (the 142x builds)

None found.

On Linux, when I called world/Reboot() and it crashed, it provided a crash dump:
(Also note the 'Delete icon', is that a debug message you accidentally left in on Linux? It's not produced by our code, and is spammed to world.log quite a bit on Linux)
Delete icon
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 512.1421 on Linux:
Generated at Mon May 14 23:10:36 2018

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24] [0xf71df000, 0x0], 0x2086f9
 [0xf7767000, 0xf7767bd0], [0xf7767000, 0xf7767bd0] [0xf71df000, 0x0], 0x2086f9 [0xf71df000, 0x0], 0x21f1c9 [0xf71df000, 0x0], 0x22002b [0xf71df000, 0x0], 0x240f32 [0xf71df000, 0x0], 0x24270e [0xf71df000, 0x0], 0x242aa3 0x35ee30, 0x35ef4a 0x325460, 0x325662
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34] 0x18540, 0x18637 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]

Recent proc calls:
Looks like something in this commit causes it: Some vis_contents bug maybe? e3e1a7ad9cc877c55f02f8d6b388809fcc07396b
The 'Delete icon' message has been gone for a release or two now, you have tried the latest, right?
I did try the latest, it still crashes. The above was on 1421 though. Just checking! Can ignore the comment about that then.
I can trace this to EmptyVisLocs() in the obj destructor, so that makes sense. What I have not been able to do is reproduce this. Starting and then stopping the server does not result in a crash for me. Are you sure you pointed me to the right source? It looks like this line is not showing up in the source I have:

T.vis_contents -= P.weather_holder.visuals

So I think you pointed me to the live source and something has changed there since your post. It's very important that I have the right source to reproduce this.
Sorry, I made a commit that reverted it last night without realizing I'd linked you directly to the branch, not as of any particular commit.

Here's a branch without the revert of the problematic vis_contents commit. I updated the OP too.
Here is a commit link: that will never change.

To get such links, go to the commit, then click browse files on the commit. Now the zip link will be the commit's zip.
Thanks MSO!
Lummox JR resolved issue with message:
Emptying vis_locs on deletion of an object caused crashes in some cases, mostly during world shutdown.
I found some suspect logic earlier and made a change. Once I was able to test the commit link in 512.1424 and confirm the crash, I tested my proposed fix against it. No crash anymore.