Author Topic: Epic Bughunt Claims Sanity, Human Blood  (Read 22342 times)

0 Members and 1 Guest are viewing this topic.

Offline High Max

  • Permanently banned
  • 29
Re: Epic Bughunt Claims Sanity, Human Blood
^^
« Last Edit: May 26, 2010, 01:23:43 am by High Max »
;-)   #.#   *_*   ^^   ^-^   ^_^

 

Offline Iss Mneur

  • 210
  • TODO:
Re: Epic Bughunt Claims Sanity, Human Blood
I knew I never used speed-matching for a reason...I just didn't realize the reason was that the engine has acquired its own "ghost." :p

Likewise, but also because I'm fairly good at just adjusting the throttle on my joystick to match my target myself

>_>

(I admit, I didn't realise there was a match speed function, but I pro'ly wouldn't use it anyway)

Oh, I will say this - you guys are... dedicated. And that's an obscure retail bug, but at least it has now been put to the sword.

Given that the scenario here in question was a non-combat cruise, match speed is a pretty useful utility function no matter what your opinions of its use in combat may be.

In any case this was a combination of speed-matching with a pairing of events. Rather specific.
Non combat cruise alright. :D I assume, that thanks to HerraTohtori's episode in the testing of the last (re)release of BP1, the weapons were locked as well (at least in the problem mission that I received) :D


As for the added error checking, I'm kinda astonished that this was not caught before. Modern CPUs are supposed to do just that and start screaming when something as stupid as this happens.

Did the modern CPU not do anything because of the fact that the game is still CPU limited? Is that another side effect of it being CPU limited?

No. It's probably a side effect from some optimisation somewhere or other.

It is not an optimization thing as we are talking about floating point numbers here. One thing about the IEEE floating point number representation system is it allows for NaN (Not a Number). Because IEEE floating point numbers were designed by a bunch of scientists, it assumes that you know what the hell you are doing and if you can't handle NaN in your data, then you need to check for it or make sure you don't generate it.

Now if we were working with integers and you divided by zero then yes, the OS actually would interrupt the program. (I just tested it, VS2008 will generate a compiler error if you use have a constant expression that evaluates to zero (C2124), and Windows 7 generates the "program has experienced a fatal error" box if you slip the fact that you are dividing by zero past the compiler.)
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

 

Offline Commander Zane

  • 212
  • Spoot Knight of Anvils
Re: Epic Bughunt Claims Sanity, Human Blood
I assume, that thanks to HerraTohtori's episode in the testing of the last (re)release of BP1...
I did have that particular episode on a TBP mission a couple days back.

 

Offline Qent

  • 29
Re: Epic Bughunt Claims Sanity, Human Blood
Wow you guys really did make it sound like something from Transcend. :P Great job on the fix!

Specifically, it's dividing zero by zero. I'm pretty sure that dividing a non-zero floating-point number by zero should always be +/-infinity.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Epic Bughunt Claims Sanity, Human Blood
Which I guess also evaluates to NaN....
Let there be light
Let there be moon
Let there be stars and let there be you
Let there be monsters and let there be pain
Let us begin to feel again
--Devin Townsend, Genesis

 

Offline Galemp

  • Actual father of Samus
  • 212
  • Current projects: GVCa Tanen, Vasudan Imperium
    • Steam
    • User page on the FreeSpace Wiki
Re: Epic Bughunt Claims Sanity, Human Blood
:jaw: I have... no words...

Consider yourself to have a drink purchased for you on my behalf, sir. Well done.
"Anyone can do any amount of work, provided it isn't the work he's supposed to be doing at that moment." -- Robert Benchley

Members I've personally met: RedStreblo, Goober5000, Sandwich, Splinter, Su-tehp, Hippo, CP5670, Terran Emperor, Karajorma, Dekker, McCall, Admiral Wolf, mxlm, RedSniper, Stealth, Black Wolf...

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Epic Bughunt Claims Sanity, Human Blood
:jaw: I have... no words...

Consider yourself to have a drink purchased for you on my behalf, sir. Well done.

Play Blue Planet!  :nervous:

sorry sorry sorry

 

Offline Qent

  • 29
Re: Epic Bughunt Claims Sanity, Human Blood
Infinity and NaN are a bit different. You can do some arithmetic on infinity, e.g. infinity is greater than every number, and negative infinity is less. But NaN just corrupts everything with its NaN-ness.

 

Offline Iss Mneur

  • 210
  • TODO:
Re: Epic Bughunt Claims Sanity, Human Blood
Infinity and NaN are a bit different. You can do some arithmetic on infinity, e.g. infinity is greater than every number, and negative infinity is less. But NaN just corrupts everything with its NaN-ness.

Ya, NaN includes more than just Infinity.  At least in the case of IEEE Floating point, NaN gets used as the catch all error state.  I am too lazy to actually look up all of the possible places to get NaN from, but as far as I know, it includes both positive and negative infinity, positive and negative number overflow (too big), and positive and negative number underflow (too small).  But yes infinity is at least order-able (you can sort it) whereas NaN is not equal to anything (even itself), not smaller than anything, and not bigger than anything

As for the result of dividing something by zero, it depends on the rules of math that you are using.  Non-calculus math completely ignores division by zero.  If your James Anderson then it is a nullity.  If you are the IEEE Floating point representation it is NaN.  Others (like Qent) consider division by zero to result in +/- infinity. According to Microsoft Visual C, division by zero results in "-1.#IND00" when represented as a string.


Also, I forgot to do this before.  I figured I should add this, because the way Battuta and The_E tell it, I just pulled the idea for this out of my ass (which I don't mind :P), but I though I would explain my thought process of how I got to the fact that is was caused by speed match, which I hope may be useful to other coders or even mission testers.

At some point I was fiddling with the logging, because I don't have the patience to frame-step through the engine like The_E (props man :yes:).  So, I was adding more logging to the engine and fiddling with debug_filter.cfg because for some reason I could get the bug to happen but not have the Assert that The_E mentioned appear (still not sure why this was happening, there very well could be another bug, but I could not get it to happen repeatably).  In the fiddling with the logging, I noticed that sometimes the bug would be completely gone, then when I would try and verify that this new logging fixed the problem (yes, I know, WTF!) it would happen again. I had a hunch at this point that it was something the user was doing to the engine that was causing the bug to manifest, but still had no idea what the source was.

I fiddled some more, and I started to get frustrated, because I was running out of options short of searching for every time the engine writes to the player position and sprinkling Asserts (which I may still do as the core of the engine just assumes that everything it gets all kosher) or log statements just to see if I could figure out which part of the engine the error was coming from so I could try and narrow it down. As a last resort, I eventually got to just rerunning the mission pressing different buttons and trying different inputs to see if I could get the error to subside, because I noticed that the logging didn't seem to help reliably. At some-point I started ramming the other other ship in the mission and of course, not setting speed match every time because Battuta or The_E would distract me or I was playing the afterburner to make the ramming more fun :D.  Obviously I eventually noticed that it didn't happen if match speed was set.  So I tried enabling match speed then disabling it; the bug happen.  Tried again and kept speed match on the entire time; it bugged out!  I tested this theory several more times, I then asked in the channel if they could confirm if the bug went away when speed match was disabled.

I then started trawling through the code to see if I could find where the engine did calculated the speed match and I seen that that there was a division that was not protected (ie. no range checking on the divisor). Yay a simple fix to a seemingly nonsensical problem.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

  

Offline Herra Tohtori

  • The Academic
  • 211
  • Bad command or file name
Re: Epic Bughunt Claims Sanity, Human Blood
Specifically, it's dividing zero by zero. I'm pretty sure that dividing a non-zero floating-point number by zero should always be +/-infinity.

Technically, no division by zero is allowed in current mathematical rule set, ever.

You can wiggle around the rules by using the concept of limit which is, of course, fundamental basis for things such as derivatives, integrals and differential calculus in general as well as series and especially infinite series, but it still isn't dividing by zero.

The formulation

lim    1 / x = ∞   (x approaches zero asymptotically from positive side)
x→0+

lim    1 / x = -∞   (x approaches zero asymptotically from negative side)
x→0-

means we can handle conditions where a variable approaches zero asymptotically, but it tends to get somewhat confusing rather easily, and a div by zero forgotten in the calculations can really throw a monkey wrench in the end result. Plus the definitions of rules of handling infinities are somewhat illogical due to the nature of such concept.

As an example, we can define that

∞ + ∞ = ∞
-∞ -∞ = (-∞) + (-∞) =  -∞

so multiplication works, but subtraction of infinities

∞ - ∞ = NaN (aka not defined)

Similarly, we can easily define that

∞ * ∞ = ∞

-∞ * -∞ = ∞

∞ * -∞ = -∞

-∞ * ∞ = -∞

so multiplication works as well... however, division is not defined:

∞/∞ = NaN (Not Defined)

There are other oddities in calculating real numbers and infinities together, such as

x / ∞ = 0

is defined and even relatively understandable... but reversing the function by multiplying with infinity doesn't work:

x / ∞ = 0  |  (...) * ∞

x * ∞ / ∞ = 0 * ∞

and because x * ∞ = ∞,

∞/∞ = 0 * ∞

and since ∞/∞ is not defined, therefore 0 * ∞ is not defined either...


 :drevil:

...actually, technically 0*∞ is every real number at the same time which, of course, is the very meaning of "undefined". :p

See what I mean by hairy definitions yet?
« Last Edit: April 17, 2010, 12:28:42 am by Herra Tohtori »
There are three things that last forever: Abort, Retry, Fail - and the greatest of these is Fail.

 

Offline Qent

  • 29
Re: Epic Bughunt Claims Sanity, Human Blood
I agree with what I can understand of all that. But I was talking about floating-point (not real number or computer integer) division by zero. I had thought that it was the IEEE that defined 1.0/0.0 as positive infinity, but if Visual C gives you that "IND" thing, then I'm not sure. GCC gives me 1.#INF00 for 1.0/0.0 and -1.#IND00 only for 0.0/0.0.

* Qent notices awkwardly how far he's dragged this off topic. :nervous:

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Epic Bughunt Claims Sanity, Human Blood
As for the added error checking, I'm kinda astonished that this was not caught before. Modern CPUs are supposed to do just that and start screaming when something as stupid as this happens.
We are talking about C and C++ here. Neither of them is going to stop you (reliably) from doing something stupid, thats something you have to stop yourself from doing.



to quote my dear father "With C you can make something either very very fast, or something very veeery stupid. In either case you'll most likely crash the bloody pc you dolt..."

Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Epic Bughunt Claims Sanity, Human Blood
Yes, however, I was more thinking in terms of compiler warnings etcetera.
Let there be light
Let there be moon
Let there be stars and let there be you
Let there be monsters and let there be pain
Let us begin to feel again
--Devin Townsend, Genesis

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Epic Bughunt Claims Sanity, Human Blood
Yes, however, I was more thinking in terms of compiler warnings etcetera.
thats true. well, thats what all the warnings are for mostly :p


wanna bet that there was one such warning somewhere during compiling that related to this bugger here?
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline Goober5000

  • HLP Loremaster
  • Administrator
  • 214
    • Goober5000 Productions
Re: Epic Bughunt Claims Sanity, Human Blood
* Goober5000 applauds

Well done guys.  I shall join in with Galemp in buying y'all a round next time you're in the area. :)

I seem to recall that this bug has been reported in ages past, back before the SCP even.  There were four or five isolated posts about everything being swallowed into inky blackness, but they have been lost to the depths of time.  People usually shrugged and moved on, because they were never able to reproduce it.  It's a testament to your perseverance that you could figure it out here.

 

Offline -Norbert-

  • 211
Re: Epic Bughunt Claims Sanity, Human Blood
"Feel free to headdesk"... pretty much yes.
I got really engrossed by the "story" of this bug and then in the end it was caused by something that every student learns (if they don't already know it) in the first or second lesson of programming.

Just proves that thinking about all the complicated stuff makes you forget the simple things sometimes.

My respects to you for finding and smashing this bug and what was necessary to do so.

 

Offline Shivan Hunter

  • 210
  • FRED needs lambdas!
Re: Epic Bughunt Claims Sanity, Human Blood
Holy crap. That bug would literally scare me if I came across it and wasn't expecting it. (I would actually consider simulating the effect in a campaign like Transcend, lol.)

And a heisenbug of that magnitude, coupled with Battman's awesome writing... I just had a nerdgasm. :o

Hats off to you all. That can NOT have been easy to find. I would never have thought of something like match-speed as one of the causes. I usually think that if it doesn't happen under certain conditions, then none of those are the primary cause, which is naturally a horrible way to try to diagnose a FSO bug. Of course, I never use match speed anyway so :\

 

Offline MatthTheGeek

  • Captain Obvious
  • 212
  • Frenchie McFrenchface
Re: Epic Bughunt Claims Sanity, Human Blood
Summed up, the problem was simply that you never considered that a retail sexp could cause such an issue, because after ten years of working and improving on the game engine, one could easily believe that every retail bug would have been fixed...

Ah, there are so many ways to crash a game engine :rolleyes: At least we can learn a lesson from this, young padawan...
People are stupid, therefore anything popular is at best suspicious.

Homeworld: Blue Planet     -     Help us help you     -     FSO Installer     -     BP extras portal     -     My legacy

666maslo666: Releasing a finished product is not a good thing! It is a modern fad.

SpardaSon21: it seems like you exist in a permanent state of half-joking misanthropy

Axem: when you put it like that, i sound like an insane person

bigchunk1: it's not retarded it's american!
bigchunk1: ...

batwota: steele's maneuvering for the coup de gras
MatthTheGeek: you mispelled grĂ¢ce
Awaesaar: grace
batwota: oh right :P
Darius: ah!
Darius: yes, i like that
MatthTheGeek: the way you just spelled it it means fat
Awaesaar: +accent I forgot how to keyboard
MatthTheGeek: or grease
Darius: the killing fat!
Axem: jabba does the coup de gras
MatthTheGeek: XD
Axem: bring me solo and a cookie

 

Offline Madcat

  • 26
Re: Epic Bughunt Claims Sanity, Human Blood
Hats off to all of you!

Since I work as an IT Consultant in Support I know quite well how hard it is to find stuff like this, spending endless hours on debugging and in the end, one or two additional lines can fix it.  :pimp:

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Epic Bughunt Claims Sanity, Human Blood
Summed up, the problem was simply that you never considered that a retail sexp could cause such an issue, because after ten years of working and improving on the game engine, one could easily believe that every retail bug would have been fixed...

Ah, there are so many ways to crash a game engine :rolleyes: At least we can learn a lesson from this, young padawan...

Also because we'd seen the issue occur before for totally different reasons. I imagine there are still ways to trigger it. And it wasn't just the retail SEXP doing it, but the combination of that SEXP with a very unusual set of circumstances that never occurs in retail and a player behavior.