Author Topic: Need your input on a fix  (Read 2288 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Need your input on a fix
« on: April 03, 2006, 09:36:07 PM »
So, this is a crashing bug I've been working on for some time.  I think I have the root cause, but I need some advice on the right fix.  FYI, debugging this one is very invovled and catching it in VB and then backtracking to the root cause has been a real pain.  I probably have 3 or 4 hours into this one so far.  

The overflow occurs in the readtie() routine when the nrg of a tied bot (I'll call it botB) is being copied into the .trefnrg sysvar of botA.  At the surface, it looks like another simple case of a single being copied into a positon in the integer valued mem array.  But the tied bot's energy is often a crazy value, like -56000 or something.  This causes the overflow, but how could the tied bot's energy get so wacked?  Well, the calculation that is causing it is the vector arithmetic in VoluntaryForces().  When it calculates the energy usage associated with botB's voluntary movement, it can end up a crazy large (positive) value.  When that large value gets subtracted from botB's nrg, it goes way negative then when trefnrg is set in botA, things go boom.

Now, it appears to happen more often for older, massive bots (like .mass >200) because .mass is used as a multiplier in the energy usage calculations for voluntary movement.  Another symptom is that one of the direction sysvars (e.g. .up, .dx. etc.) is a huge value, like in the thousands or ten thousands.  This is what throws the vector math for a loop and results in the crazy high ernegy usage calculations.

So, this was really puzzling me.  I suppose another bot could be using venom to write really wacky values into .up, etc. or maybe the bot mutated to do it to itself, though I thought the code did a good job of policing those values and chopping them if they were excessive.  Then I noticed the waste on botB is sufficiently high to trigger the altzheimer routine.  So, what I suspect (though have yet to really prove) is that in the case where a massive bot builds up enough waste, random stuff gets stuffed into the mem array and this bypasses the special location limit checking and if that value has a large enough value independent of sign and is in the right mem location (like .up, etc) then the calculations lead to the crash.

So, I have a philospohical question.  I can prevent the crash, but what is the right behaviour for botB?  All the memory locations of a bot are not created equal.  In theory, they are all Integers and one could take the position that the altzheimer routine (or venom or a mutation or a virus) should be able to write any value from -32000 to +32000 into any location and the engine should just handle that and do what that means and if that means that a huge bot with lots of mass and energy gets it all used up in one cycle becuase the altzheimer random write tells the engine to try to accelerate .up at 30,000 then so be it.  Poof, a huge, healthy, otherwise well evolved bot takes a ton of energy out of the sim in one go just because it didn't take a crap - excuse me, manage it's waste correctly (I think this is happening today).  Or, should I try to police "special" locations in the mem array from the altzheimer routine and potentially other ways crazy values can get written by limiting accelerations to between 0 and 1000 (as it indicates in the wiki), limiting energy loss to 100 max per cycle, etc.

I hate special cases and privledged locations and special code to police magic numbers, but I do think I want to do the latter.

Any and all advice is welcome.

-E
« Last Edit: April 03, 2006, 09:36:56 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Need your input on a fix
« Reply #1 on: April 03, 2006, 09:49:29 PM »
Ideally the voluntary forces function caps the magnitude of the resulting acceleration vector, which should cap the max energy used.  This becomes tricky in 2.4 since acceleration depends on mass.

I wouldn't like to change the way alxheimers works, but I would like to cap values that are too insane for things like movemet.