DreamDaemon Crash on world/Reboot or /Del

BYOND Forums

Announcements · BYOND Help · Bug Reports · Feature Requests · Beta Testers · Beta Bugs · Developer Help · Design Philosophy · Demos & Libraries · Tutorials & Snippets · Art & Sound · Classified Ads · Game Updates · Contests & Events · Linux Talk · On Topic · Off Topic

ID:2369089

May 14 2018, 9:21 pm (Edited on May 15 2018, 4:38 pm)

Arokha

Resolved

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 https://github.com/VOREStation/VOREStation/archive/ aro-shelterquol.zip 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)

Workarounds:
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]
libbyond.so [0xf71df000, 0x0], 0x2086f9
 [0xf7767000, 0xf7767bd0], [0xf7767000, 0xf7767bd0]
libbyond.so [0xf71df000, 0x0], 0x2086f9
libbyond.so [0xf71df000, 0x0], 0x21f1c9
libbyond.so [0xf71df000, 0x0], 0x22002b
libbyond.so [0xf71df000, 0x0], 0x240f32
libbyond.so [0xf71df000, 0x0], 0x24270e
libbyond.so [0xf71df000, 0x0], 0x242aa3
libbyond.so 0x35ee30, 0x35ef4a
libbyond.so 0x325460, 0x325662
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x18540, 0x18637 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]

Recent proc calls:
/proc/key_name
/proc/log_access_out
/datum/nanomanager/proc/close_user_uis
/datum/nanomanager/proc/user_logout
/mob/Logout
/mob/observer/dead/Logout
/client/Del
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/effect/effect/system/ion_trail_follow/start
/datum/controller/processScheduler/proc/start

May 14 2018, 11:03 pm
Arokha	Looks like something in this commit causes it: Some vis_contents bug maybe? https://github.com/VOREStation/VOREStation/commit/ e3e1a7ad9cc877c55f02f8d6b388809fcc07396b

May 14 2018, 11:17 pm
Nadrew	The 'Delete icon' message has been gone for a release or two now, you have tried the latest, right?

May 14 2018, 11:18 pm
Arokha	I did try the latest, it still crashes. The above was on 1421 though. Just checking! Can ignore the comment about that then.

May 15 2018, 12:17 pm

Lummox JR

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.

May 15 2018, 4:38 pm
Arokha	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. https://github.com/VOREStation/VOREStation/archive/ aro-shelterquol.zip Here's a branch without the revert of the problematic vis_contents commit. I updated the OP too.

May 15 2018, 6:35 pm
MrStonedOne	Here is a commit link: https://github.com/VOREStation/VOREStation/archive/ 58189980d27c815c066cf6768a9eb03321af78c6.zip 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.

May 15 2018, 6:36 pm
Arokha	Thanks MSO!

May 15 2018, 8:46 pm
Lummox JR	Lummox JR resolved issue with message: Emptying vis_locs on deletion of an object caused crashes in some cases, mostly during world shutdown.

May 15 2018, 8:48 pm
Lummox JR	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.