ID:2212191
 
BYOND Version:511.1370
Operating System:Linux
Web Browser:Firefox 51.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
DreamDaemon crashing


Numbered Steps to Reproduce Problem:
If server rebooting and starts loading the map. But not always.



Code Snippet (if applicable) to Reproduce Problem:
World rebooted at 470000
Running /tg/ revision:
2017-02-12
883c2bfc510ce9d7395f9f240db80442e3486b98
Current map - Box Station
runtime error:
[16:03:24]Cannot execute null.copy from().
[16:03:24]proc name: Assimilate Air (/turf/open/proc/Assimilate_Air)
[16:03:24] source file: turf.dm,253
[16:03:24] usr: null
[16:03:24] src: the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor)
[16:03:24] call stack:
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): Assimilate Air()
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): AfterChange(0)
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): ChangeTurf(/turf/open/floor/mech_bay_rech... (/turf/open/floor/mech_bay_recharge_floor), 0, 0)
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): ChangeTurf(/turf/open/floor/mech_bay_rech... (/turf/open/floor/mech_bay_recharge_floor))
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): ChangeTurf(/turf/open/floor/mech_bay_rech... (/turf/open/floor/mech_bay_recharge_floor))
[16:03:24]the mech bay recharge station (125,173,1) (/turf/open/floor/mech_bay_recharge_floor): New()
World loaded at 470080
Database connection established.
Initialized Jobs subsystem within 0 seconds!
Ruin "Syndicate Lava Base" placed at (144, 26, 5)
Ruin "Ruin of Envy" placed at (85, 121, 5)
Ruin "Biodome Winter" placed at (112, 188, 5)
Ruin "Biodome Clown Planet" placed at (35, 181, 5)
Ruin "Ruin of Greed" placed at (140, 179, 5)
Ruin "UFO Crash" placed at (153, 112, 5)
Ruin "Ruin of Sloth" placed at (210, 23, 5)
Ruin "Hierophant's Arena" placed at (175, 127, 5)
Ruin "Fountain Hall" placed at (63, 194, 5)
Ruin "A Giant Ball of Paper in Space" placed at (160, 41, 6)
Ruin "Aesthetic Outpost" placed at (208, 65, 9)
Ruin "Crashed Clown Ship" placed at (181, 51, 8)
Ruin "Strange Ship" placed at (16, 69, 6)
Ruin "Syndicate Ambush" placed at (154, 90, 4)
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 511.1370 on Linux:
Generated at Sun Feb 12 16:03:41 2017

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xe48c8000, 0x0], 0x21de40
linux-gate.so.1 [0xe4e43000, 0xe4e43410], [0xe4e43000, 0xe4e43410]
libbyond.so [0xe48c8000, 0x0], 0x21de40
libbyond.so [0xe48c8000, 0x0], 0x22283c
libbyond.so 0x335cc0, 0x335dda
libbyond.so 0x2ff910, 0x2ffb12
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x18500, 0x185f7 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]

Recent proc calls:
/datum/subsystem/garbage_collector/proc/HardQueue
/atom/movable/proc/has_buckled_mobs
/atom/movable/proc/unbuckle_all_mobs
/atom/proc/handle_atom_del
/datum/proc/Destroy
/atom/Destroy
/atom/Destroy
/atom/movable/Destroy
/atom/movable/Destroy
/proc/qdel
/atom/movable/Destroy
/atom/movable/Destroy
/mob/proc/ghostize
/mob/proc/spellremove
/datum/subsystem/garbage_collector/proc/QueueForQueuing
/datum/proc/Destroy

To help the BYOND developers debug this, please send the above trace as part
of a very detailed bug report: http://www.byond.com/members/?command=view_tracker&tracker=1




BUG: Crashing due to an illegal operation!

Backtrace for BYOND 511.1370 on Linux:
Generated at Sat Feb 11 19:25:19 2017

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xe9c45000, 0x0], 0x21de40
linux-gate.so.1 [0xea1c0000, 0xea1c0410], [0xea1c0000, 0xea1c0410]
libbyond.so [0xe9c45000, 0x0], 0x21de40
libbyond.so [0xe9c45000, 0x0], 0x22283c
libbyond.so 0x335cc0, 0x335dda
libbyond.so 0x2ff910, 0x2ffb12
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x18500, 0x185f7 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 511.1370 on Linux:
Generated at Fri Feb 10 15:27:09 2017

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xf0612000, 0x0], 0x21de40
linux-gate.so.1 [0xf0b8d000, 0xf0b8d410], [0xf0b8d000, 0xf0b8d410]
libbyond.so [0xf0612000, 0x0], 0x21de40
libbyond.so [0xf0612000, 0x0], 0x22283c
libbyond.so 0x335cc0, 0x335dda
libbyond.so 0x2ff910, 0x2ffb12
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x18500, 0x185f7 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]
I'm confused on your report. The subject line says this happens on restart; but the numbered steps to reproduce the problem are blank, and under "When does the problem NOT occur" you said "When server rebooting"? Does the problem occur during restart, or at some other time? Either way, you need to edit your report to fix it, because it's contradicting itself right now.

I traced the crash to a routine that sends HUD updates to a client. Although the crash is consistently happening in this same spot based on the traces you posted, I can see no way for this list to have gotten corrupted. Any heap corruption, especially occurring as a result of running out of memory, should be more varied in its results.

If this issue happens on reboot (we still need to clear that up), does it happen consistently?
Nope, this is not happens consistently, only when server at high load, i think. Other two reports dont have other logs, im sorry for this. Reproducing problem looks like: rebooting server when its on high load and then sometimes we got crash. I can add more logs, when server got crashed in future.
So to clarify, this happens only during a reboot? If so you should edit your report, because the "Numbered steps" portion is incorrect and so is the "When does the problem NOT occur" answer.
Yes, after reboot and when server starts load a map. Edited topic a little.
Looking into this further, I wonder if the problem is that a client is disconnecting under these circumstances--which it could if your reboot load is heavy. I added another sanity check that might well prevent this problem in 511.1374.