Random Bug in Dragon Universe - Constantly happening.

ID:2147236
 
Sep 12 2016, 10:41 pm
BYOND Version:510
Operating System:Linux
Web Browser:Chrome 52.0.2743.116
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
There are two Dragon Universe servers running on a single VPS. One of them has not exhibited issues related to this bug report. But, the other one has constantly shown signs of this bug repeating. So, I'm going to start a post on this matter.

Bug Report:
BUG: Crashing due to an illegal operation!
Tue Sep 13 00:28:40 2016
proc name: Leech (/mob/proc/Leech)
  usr: 0
  src: Valkyrie (/mob)
  src.loc: GroundSandDark (102,273,1) (/turf/GroundSandDark)
  call stack:
Valkyrie (/mob): Leech(The Chef (/mob), 2.92969e+09, 1, 0, 1, 0)
Valkyrie (/mob): Zenkai(0.5)
Valkyrie (/mob): Death(The Chef (/mob), 0, 0, 1, 1)
Blast (/obj/Blast): Bump(Valkyrie (/mob), null, null)
Blast (/obj/Blast): Move(GroundSandDark (102,273,1) (/turf/GroundSandDark), 1, 0, 0)
The Chef (/mob): Blast Fire(Blast (/obj/Attacks/Blast))

Backtrace for BYOND 510.1346 on Linux:
Generated at Tue Sep 13 00:28:40 2016

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xf725f000, 0x0], 0x1c39c5
 [0xf77a5000, 0xf77a5420], [0xf77a5000, 0xf77a5420]
libbyond.so [0xf725f000, 0x0], 0x1c39c5
libbyond.so [0xf725f000, 0x0], 0x22acb8
libbyond.so [0xf725f000, 0x0], 0x260cc6
libbyond.so [0xf725f000, 0x0], 0x23f2c4
libbyond.so [0xf725f000, 0x0], 0x257cfe
libbyond.so [0xf725f000, 0x0], 0x260513
libbyond.so [0xf725f000, 0x0], 0x26117d
libbyond.so [0xf725f000, 0x0], 0x23e210
libbyond.so [0xf725f000, 0x0], 0x257cfe
libbyond.so [0xf725f000, 0x0], 0x260513
libbyond.so [0xf725f000, 0x0], 0x261030
libbyond.so [0xf725f000, 0x0], 0x23e210
libbyond.so [0xf725f000, 0x0], 0x257cfe
libbyond.so [0xf725f000, 0x0], 0x260513
libbyond.so [0xf725f000, 0x0], 0x261030
libbyond.so [0xf725f000, 0x0], 0x23e210
libbyond.so [0xf725f000, 0x0], 0x257cfe
libbyond.so [0xf725f000, 0x0], 0x260513
libbyond.so [0xf725f000, 0x0], 0x2618ab
libbyond.so [0xf725f000, 0x0], 0x1b600a
libbyond.so [0xf725f000, 0x0], 0x1beede
libbyond.so [0xf725f000, 0x0], 0x25b991
libbyond.so [0xf725f000, 0x0], 0x263b1d
libbyond.so [0xf725f000, 0x0], 0x23c335
libbyond.so [0xf725f000, 0x0], 0x257cfe
libbyond.so [0xf725f000, 0x0], 0x260513
libbyond.so [0xf725f000, 0x0], 0x2618ab
libbyond.so [0xf725f000, 0x0], 0x1b89c8
libbyond.so [0xf725f000, 0x0], 0x1b8c6d
libbyond.so [0xf725f000, 0x0], 0x2a060a
libbyond.so [0xf725f000, 0x0], 0x2409db
libbyond.so [0xf725f000, 0x0], 0x257acc
libbyond.so [0xf725f000, 0x0], 0x259135
libbyond.so [0xf725f000, 0x0], 0x2148e9
libbyond.so 0x32e770, 0x32e88a
libbyond.so 0x2f8600, 0x2f8802
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x199e0, 0x19ad3 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]

Recent proc calls:
/mob/proc/Vegitoss4Boost
/mob/proc/Dead_power
/mob/proc/BodySwapBPMult
/mob/proc/weights
/mob/proc/Powerup_mult
/mob/proc/Anger_mult
/mob/proc/Anger_Powerup_Mix_Mult
/mob/proc/hp_mult
/mob/proc/ki_mult
/mob/proc/Splitform_Count
/proc/Clamp
/mob/proc/Powerup_mult
/mob/proc/ki_mult
/mob/proc/Icer_Form_Addition
/mob/proc/kaioken_bp
/mob/proc/Is_oozaru

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


Full Log File:
https://www.dropbox.com/s/dvbewgmixojssk4/Errors.log?dl=0
The full log file is 6MB big. Primarily because the game always seems to spam HTTP error. Tens and ExGenesis told me a few years back that it had to do with their Export() calls to their website. I didn't particularly care that it spammed. Except for the fact that it can cause some issues with games when you log to an already massive log file (something I've seen happen with other games that do things like this).

I believe the game logs this error about 8 times every time a user logs in. This server had an average of 40 players. So you can imagine that is would fill up pretty quickly and have a lot of issues.
Sep 13 2016, 4:28 am
Export() will only give an HTTP error if it fails to connect or doesn't receive a valid HTTP response; even simply sending back "HTTP/1.1 200 OK\r\n\r\n" or "HTTP/1.1 204 No Content\r\n\r\n" before closing the connection is enough.
Sep 13 2016, 9:30 am
I tried a little tracing on this last night, but this one is turning out to be super difficult.

It would help a lot if I had the source available, especially for Vegitoss4Boost() which was the last-called proc (it appears this is happening inside a proc call), but I'm guessing you don't have that.
Sep 13 2016, 10:19 am
The call where the crash is occurring appears to be GetMob(). However, the crash is happening on a line where crashing should be impossible. Namely, it's simply reading a value off the stack. If the stack pointer is valid, that should never happen; and if it's not valid, then I would expect the crash to happen earlier.

If you have any additional crash logs, they may be helpful in narrowing this issue down.
Sep 13 2016, 10:57 am
Yeah, I will keep posting updates here as the crashes happen. If you need me to trace anything on my end let me know; since it is hanging.

I will also inform Tens (or ExGenesis) to participate in this post since it is their game. This way they can present code snippets.
Sep 13 2016, 11:03 am
In response to Lummox JR
Lummox JR wrote:
I tried a little tracing on this last night, but this one is turning out to be super difficult.

It would help a lot if I had the source available, especially for Vegitoss4Boost() which was the last-called proc (it appears this is happening inside a proc call), but I'm guessing you don't have that.

Unfortunately, the source to the files Xirre is running got lost a few weeks back. I'll see if I can find it though.
Sep 14 2016, 10:47 am (Edited on Sep 15 2016, 6:00 am)
Hello I'm a coder for DU and I'm here to give you a clue. I lost the DU source. Meaning I have no recollection of what this Vegitoss4Boost proc had in it specifically. But I do remember it had a line something like this:
var/expiration_date = 5223753998
if(world.realtime > expiration_date) return //don't give the boost past this date (it is expired)


I've had problems with adding 32 bit numbers directly into the code in the compiler before. It has caused crashes or something I don't remember specifically.
Lummox I think you know what I'm talking about better than I do. I think the problem lies in that line because the rest of the code was very basic.
Sep 14 2016, 10:48 am
And thanks Xirre and EXGenesis. Luv u guys ;)
Sep 15 2016, 6:54 am
In response to Tens of DU
Tens of DU wrote:
var/expiration_date = 5223753998
if(world.realtime > expiration_date) return //don't give the boost past this date (it is expired)

A literal integer higher than 2147483648 is clamped to 2147483648 when parsed; if you want the actual value 5223753998, you'll need to use a *float* literal (ie 5223753998.0), which will round to 5223754240.

http://www.byond.com/forum/?post=1959798
Sep 15 2016, 9:06 am
Yeah, I don't think the high number should cause a crash. It never makes it intact past the parser at compile-time, so there's really no way it can cause that kind of behavior.
Sep 19 2016, 10:53 am
I think it hung a day or two ago. But, here's the log.

BUG: Crashing due to an illegal operation!
Mon Sep 19 12:48:18 2016
proc name: Raise Stats (/mob/proc/Raise_Stats)
  usr: (src)
  src: Akihiko{Blue Demon Swordsman} (/mob)
  src.loc: Ground17 (250,250,18) (/turf/Ground17)
  call stack:
Akihiko{Blue Demon Swordsman} (/mob): Raise Stats(2, null)
Akihiko{Blue Demon Swordsman} (/mob): Attack Gain(-nan, null, 1, 1)
Akihiko{Blue Demon Swordsman} (/mob): Vegetas core gains()
Akihiko{Blue Demon Swordsman} (/mob): Start core loops()
Akihiko{Blue Demon Swordsman} (/mob): update area()
Akihiko{Blue Demon Swordsman} (/mob): Move(Teleporter (6,5,11) (/turf/Teleporter/Teleporter), 6, 0, 0)
Akihiko{Blue Demon Swordsman} (/mob): move loop()

Backtrace for BYOND 510.1346 on Linux:
Generated at Mon Sep 19 12:48:18 2016

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bb24]
libbyond.so [0xf722e000, 0x0], 0x1da544
 [0xf7774000, 0xf7774420], [0xf7774000, 0xf7774420]
libbyond.so [0xf722e000, 0x0], 0x1da544
libbyond.so [0xf722e000, 0x0], 0x22ad0c
libbyond.so [0xf722e000, 0x0], 0x260cc6
libbyond.so [0xf722e000, 0x0], 0x23f2c4
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x261030
libbyond.so [0xf722e000, 0x0], 0x23e210
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x261030
libbyond.so [0xf722e000, 0x0], 0x23e210
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x261030
libbyond.so [0xf722e000, 0x0], 0x23e210
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x261030
libbyond.so [0xf722e000, 0x0], 0x23e210
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x26117d
libbyond.so [0xf722e000, 0x0], 0x23e210
libbyond.so [0xf722e000, 0x0], 0x257cfe
libbyond.so [0xf722e000, 0x0], 0x260513
libbyond.so [0xf722e000, 0x0], 0x2618ab
libbyond.so [0xf722e000, 0x0], 0x1b89c8
libbyond.so [0xf722e000, 0x0], 0x1b8c6d
libbyond.so [0xf722e000, 0x0], 0x2a060a
libbyond.so [0xf722e000, 0x0], 0x2409db
libbyond.so [0xf722e000, 0x0], 0x257acc
libbyond.so [0xf722e000, 0x0], 0x259135
libbyond.so [0xf722e000, 0x0], 0x2148e9
libbyond.so 0x32e770, 0x32e88a
libbyond.so 0x2f8600, 0x2f8802
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ae34]
libc.so.6 0x199e0, 0x19ad3 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a731]

Recent proc calls:
/mob/proc/Raise_Stats
/proc/Clamp
/mob/proc/GravityGainsMult
/mob/proc/decline_gains
/mob/proc/Has_Naoya_Perks
/mob/proc/Raise_BP
/mob/proc/weights
/mob/proc/decline_gains
/mob/proc/Decline_Energy_Gain
/mob/proc/Raise_Ki
/mob/proc/balance_rating
/mob/proc/Stat_Avg
/mob/proc/balance_rating
/mob/proc/Stat_Avg
/mob/proc/Stat_Gain
/mob/proc/balance_rating

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


Full Log File: https://www.dropbox.com/s/2jk1d5aa5xsu1io/Error2.log?dl=0
Sep 19 2016, 12:25 pm
This latest crash appears to be happening in the get routine for a soft var. The cause of the crash however is not clear at all. Again it would help to see the source at the point in question.