Ubuntu DreamDaemon Crash - The Return

Page: 1 2 3 4
ID:1407161
 
Oct 26 2013, 9:05 pm
Resolved
Calling image/new() with no arguments caused junk data to be used, sometimes resulting in a crash.
BYOND Version:501
Operating System:Linux
Web Browser:Firefox 26.0
Applies to:Dream Daemon
Status: Resolved (503.1224)
This issue has been resolved.
Descriptive Problem Summary:
DreamDaemon sometimes crashes at random intervals again, completely shutting down the DreamDaemon process with a log output thrown if started with the -logself flag.

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ab18]
libbyond.so 0x2e85d0, 0x2e85ec
 [0xf777a000, 0xf777a410], [0xf777a000, 0xf777a410]
libbyond.so 0x2e85d0, 0x2e85ec
libbyond.so 0x24b270, 0x24b592
libbyond.so 0x25cfb0, 0x25cfde
libbyond.so 0x25d130, 0x25d214
libbyond.so [0xf722b000, 0x0], 0x283258
libbyond.so [0xf722b000, 0x0], 0x2bdfa0
libbyond.so [0xf722b000, 0x0], 0x2a5929
libbyond.so 0x2b51c0, 0x2b52de
libbyond.so 0x2bc7e0, 0x2bc893
libbyond.so [0xf722b000, 0x0], 0x2bd268
libbyond.so [0xf722b000, 0x0], 0x2a6581
libbyond.so 0x2b51c0, 0x2b52de
libbyond.so 0x2bc7e0, 0x2bc893
libbyond.so [0xf722b000, 0x0], 0x2bd465
libbyond.so [0xf722b000, 0x0], 0x2a65c2
libbyond.so 0x2b51c0, 0x2b52de
libbyond.so 0x2bc7e0, 0x2bc893
libbyond.so 0x2be100, 0x2be1c0
libbyond.so [0xf722b000, 0x0], 0x2b71de
libbyond.so 0x2bc7e0, 0x2bc9a3
libbyond.so 0x2be100, 0x2be1c0
libbyond.so 0x262950, 0x262e7b
libbyond.so [0xf722b000, 0x0], 0x26a64e
libbyond.so [0xf722b000, 0x0], 0x2784f0
libbyond.so 0x279f40, 0x279fc0
libbyond.so 0x2c43e0, 0x2c4457
libbyond.so 0x319490, 0x3196b6
libbyond.so [0xf722b000, 0x0], 0x31a005
libbyond.so 0x31bdd0, 0x31c52d
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a5ac]
libc.so.6 0x16d60, 0x16e46 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049ff1]


This is the last crash report in our game's log file. If there's any other information you need to diagnose this problem let me know.

We're using v501.1216 DreamDaemon from the download page.
Oct 27 2013, 10:45 am
Also we've been getting a tremendous amount of errors that look like this:

http://pastebin.com/vtVPhjVV


They seemed to begin immediately after the crash. This makes some of our players' savefiles extremely volatile, with random abilities being deleted on whim.

The errors are very much not related to the game, as they seem to imply those types don't exist, which they do. I'd really appreciate any kind of response on this.
Oct 28 2013, 6:27 am
I'll try to look into this. I'm not sure if the savefile issue is more of a cause or effect. Given that the old crash/freeze problems related to the way BYOND was built for Linux before, I have to think that's taken care of and this is a separate issue.

I'm not sure I'll be able to get anything concrete without the game's source or an example of some of the broken savefiles, but even then this might be hard to get to the bottom of. With code as complicated as Eternia's, I can never be sure what bits might be triggering the crash. The only reliable path to a solution is when there's a reliable way to reproduce the problem.
Oct 28 2013, 9:19 am
Something seems wrong here. The offsets from that crash report aren't meshing up in the file I'm looking at from our 501.1216 Linux build. This reminds me of the issue Stephen001 ran into at one point with his debugger reporting offsets that were nowhere near correct. I'm not sure what to make of it.
Oct 28 2013, 2:28 pm
Is there anything I could do to provide more information on this?
Oct 28 2013, 3:33 pm
I'm not sure. All I can say for sure is that when I analyze libbyond.so from the Linux build, the offsets I have don't match up with yours.
Oct 29 2013, 12:57 am
Is this an amd64/x86_64 installation of Ubuntu? Also, what version of Ubuntu is this? Desktop or Server?

Also, what versions (and architectures) of the following to you have? Some may not be installed at all.

libstdc++6
libc6
libgcc1
ia32-libs (if it's an amd64/x86_64 installation)
Oct 29 2013, 9:26 am
We are using libstdc++6 and I think (but can't be sure) we are using ia32-libs
Oct 29 2013, 9:38 am
Lummox: will you need an update to date version of the source code to efficiently look into things? If so, I'll e-mail it, along with the corrupted savefiles.
Oct 29 2013, 11:21 am
In response to Doohl
Question is, which versions? And one which version of Ubuntu?
Oct 29 2013, 11:38 am
This may be a bit extreme, but why not clone the disk the server is running on, and send it to a BYOND Staff to debug?
That way, they'll know exactly what state the server is in, and perhaps could reliably reproduce the crash?
Oct 29 2013, 11:52 am
Well, that's many 10's of gig over the net at very least.
Oct 29 2013, 12:19 pm
We're switching servers constantly due to unrelated issues, so we'll get back to you on the exact specs eventually. But generally we're using the 'latest' version of libstdc++6 and Ubuntu 13.x.

The problem persists throughout the servers we're using, however.
Oct 29 2013, 12:24 pm
Which Ubuntu 13? They've released 13.04 and 13.10 by now. And amd64, or i386?
Oct 29 2013, 12:48 pm
Again, we don't have exact specs because we're constantly hopping between servers. I'll be able to answer that eventually, but pretty sure it was 13.04.
Oct 30 2013, 2:58 pm (Edited on Oct 30 2013, 3:41 pm)
More error logs, in case it helps at all:

Backtrace for BYOND 501.1216 on Linux:
Generated at Wed Oct 30 20:47:58 2013

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ab18]
libbyond.so 0x24b1f0, 0x24b3fa
 [0xb772b000, 0xb772b600], [0xb772b000, 0xb772b600]
libbyond.so 0x24b1f0, 0x24b3fa
libbyond.so 0x25cf30, 0x25cf5e
libbyond.so 0x25d0b0, 0x25d194
libbyond.so [0xb71d9000, 0x0], 0x2831b8
libbyond.so [0xb71d9000, 0x0], 0x2bdf00
libbyond.so [0xb71d9000, 0x0], 0x2a5889
libbyond.so 0x2b5120, 0x2b523e
libbyond.so 0x2bc740, 0x2bc7f3
libbyond.so [0xb71d9000, 0x0], 0x2bd1c8
libbyond.so [0xb71d9000, 0x0], 0x2a64e1
libbyond.so 0x2b5120, 0x2b523e
libbyond.so 0x2bc740, 0x2bc7f3
libbyond.so [0xb71d9000, 0x0], 0x2bd1c8
libbyond.so [0xb71d9000, 0x0], 0x2a64e1
libbyond.so [0xb71d9000, 0x0], 0x2b501c
libbyond.so 0x2b6450, 0x2b6555
libbyond.so [0xb71d9000, 0x0], 0x27c254
libbyond.so 0x34c420, 0x34c5bc
libbyond.so 0x31bd30, 0x31bf39
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a5ac]
libc.so.6 0x19840, 0x19935 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049ff1]



BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:165)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:166)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:173)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:174)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:175)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:176)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:179)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:180)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:271)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:274)
BUG: Bad ref (6:43309) in DecRefCount(DM spell_tree.dm:275)
BUG: Bad ref (6:43309) in DecRefCount(DM summon.dm:34)
BUG: Bad ref (6:43309) in DecRefCount(DM summon.dm:34)
BUG: Bad ref (6:43309) in DecRefCount(DM summon.dm:34)
BUG: Bad ref (6:43309) in DecRefCount(DM summon.dm:34)
BUG: Crashing due to an illegal operation!
Oct 30 2013, 3:40 pm
All of the errors in spell_tree.dm have something to do with maptext. Here's a few of them:

I.maptext_width = 180          // 165
I.maptext_height = 276         // 166



I.maptext = "<font color='white'>[text]"      // 180


However, the last error that happens 4 times is related to a ..() call under mob/Del()

    Del()
        for(var/mob/creature/S in summons)
            S.loc = null
            S.health = 0
            spawn(50) del(S)
        ..()     // 34


Hope this helps.

EDIT: I noticed something stupid in the code above. spawn(50) del(S) should be problematic because it is scheduling a delete call when the parent mob is deleted. Would this be why it's generating an error?
Oct 30 2013, 3:49 pm
I'll explain what's going on in spell_tree.dm:

Basically an image is being created, which is being used to overlay a parent hud object. The image I is being assigned a new maptext value for every different bit of information that needs to be displayed; and such, the pixel offsets are changed as well.

A peculiar trend I noticed is that when the image I's pixel_y is modified, it generates an error.

I.pixel_y = -2      // 176
...
I.pixel_y=0         // 179
...
I.pixel_y += 2      // 274


Essentially it accounts for every instance of a pixel_y modification except for this one:

I.pixel_y = -128    // 270


I'm not sure if this is relevant but hopefully it provides some insight.
Oct 31 2013, 12:34 am
 
World opened on network port 1213.
Welcome BYOND! (5.0 Beta Version 501.1216)
Making temporary copy of /root/Eternia/Eternia.dyn.rsc
The BYOND hub reports that port 1213 is reachable.
BUG: Removing corrupt rsc entry 'male pale.dmi'
BUG: Removing corrupt rsc entry 'male pale.dmi'
BUG: Removing corrupt rsc entry 'male pale.dmi'
BUG: Removing corrupt rsc entry 'male pale.dmi'
BUG: Removing corrupt rsc entry 'male pale.dmi'
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 501.1216 on Linux:
Generated at Thu Oct 31 04:57:08 2013

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ab18]
libbyond.so 0x2e8530, 0x2e854c
 [0xb77b8000, 0xb77b8600], [0xb77b8000, 0xb77b8600]
libbyond.so 0x2e8530, 0x2e854c
libbyond.so 0x24b1f0, 0x24b512
libbyond.so 0x25cf30, 0x25cf5e
libbyond.so 0x25d0b0, 0x25d194
libbyond.so [0xb7266000, 0x0], 0x2831b8
libbyond.so [0xb7266000, 0x0], 0x2bdf00
libbyond.so [0xb7266000, 0x0], 0x2a5889
libbyond.so 0x2b5120, 0x2b523e
libbyond.so 0x2bc740, 0x2bc7f3
libbyond.so [0xb7266000, 0x0], 0x2bd1c8
libbyond.so [0xb7266000, 0x0], 0x2a64e1
libbyond.so 0x2b5120, 0x2b523e
libbyond.so 0x2bc740, 0x2bc7f3
libbyond.so [0xb7266000, 0x0], 0x2bd3c5
libbyond.so [0xb7266000, 0x0], 0x2a6522
libbyond.so 0x2b5120, 0x2b523e
libbyond.so 0x2bc740, 0x2bc7f3
libbyond.so 0x2be060, 0x2be120
libbyond.so [0xb7266000, 0x0], 0x2b713e
libbyond.so 0x2bc740, 0x2bc903
libbyond.so 0x2be060, 0x2be120
libbyond.so 0x2628d0, 0x262dfb
libbyond.so [0xb7266000, 0x0], 0x26a5ce
libbyond.so [0xb7266000, 0x0], 0x278470
libbyond.so 0x279ec0, 0x279f40
libbyond.so 0x2c4340, 0x2c43b7
libbyond.so 0x3193f0, 0x319616
libbyond.so [0xb7266000, 0x0], 0x319f65
libbyond.so 0x31b890, 0x31bbeb
libbyond.so 0x31bd30, 0x31bf44
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a5ac]
libc.so.6 0x19840, 0x19935 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049ff1]
Oct 31 2013, 12:48 am
In response to Stephen001
Stephen001 wrote:
Is this an amd64/x86_64 installation of Ubuntu? Also, what version of Ubuntu is this? Desktop or Server?

Also, what versions (and architectures) of the following to you have? Some may not be installed at all.

libstdc++6
libc6
libgcc1
ia32-libs (if it's an amd64/x86_64 installation)

Any updates on this information? It's pretty much required to work out how to resolve the issue of offsets not lining up. The ia32-libs one in particular, is quite important.
Page: 1 2 3 4