Bugs, bugs and more bugs?

04-24-2007, 07:26 AM

Well, I keep reading about the so called "timer variable set to null bug".
It never existed for me, as I nullify every timer variable and I never ever got a bug, maybe I'm just lucky...

Quote:

In very rare situations, setting a variable (most often a timer) which content’s you use with the return bug can cause problems. It seems like it sometimes resets the object’s handle id.

Ok, now I encountered some bugs which almost gave me an heartattack.
Firstly, checking wether a removed/destroyed handle variable is null or not does not work. It is never null, for some reason, even if it's destroyed/removed.
Secondly...uh...I don't even know how to summerize it, that's why I uploaded this map for you to see.
In the trigger "Arrow Shot", there is a line which nullifies a local unit variable, set arrow = null.
If you comment this line out, it won't bug. If you leave it as it is thus nullify this variable, it will bug, and it does not bug in very rare situations, like, you will see the bug after a maximum of 10 casts.
This has, at least to me, no meaning.
The arrow (missle) does not even have any Handle Vars attached, and it's a local variable too...but I'm sure it has something to do with the dynamic trigger, because (I think) it only starts bugging after hitting someone.

Attached Files

missles_test.w3x (34.0 KB)

04-24-2007, 07:33 AM	#2
Jazradel	It's not null if it's been destroyed. The handle it points too has been removed, but it still points to it. The arrow didn't bug for me at all. If it does for you, it'll be because shoot() uses handles and has the bug.

04-24-2007, 11:52 AM	#3
UnMi	Hmm...still points to it...I'm not quite sure what this means... What is it pointing to, if there is nothing to point? And the arrow does bug, I didn't make myself clear enough: Now I updated the map and the post, try it again.

04-24-2007, 12:18 PM

Rising_Dusk

Quote:

Hmm...still points to it...I'm not quite sure what this means...
What is it pointing to, if there is nothing to point?

It leaves a 4 byte temporary reference where the handle once was that goes away when the pointers are nulled.
Or something like that, I'm pretty sure I'm right but Pipedream/Vex could direct you further.

JASS:

function shoot takes unit missle, real angle returns nothing
    local timer t = CreateTimer()
    local trigger tr = CreateTrigger()
    call SetHandleReal(t,"Angle",angle)
    call SetHandleHandle(t,"Missle",missle)
    call SetHandleHandle(t,"Shot Trigger",tr)
    call SetHandleHandle(tr,"Action",TriggerAddAction(tr,function shoot_hit))
    call SetHandleHandle(tr,"Shoot Timer",t)
    call SetHandleHandle(tr,"Missle",missle)
    call TriggerRegisterUnitInRange(tr,missle,150.00,null)
    call TimerStart(t,0.05,true,function shoot_loop)
    set t = null
    set tr = null
endfunction

This is a known problem in using handle variables.
If you nullify a timer upon which you attach variables, it has a slight chance to bug and handle references will start returning invalid numbers.
You do this in two places.

You also do not have a triggercondition attached to the trigger, yet you attempt to remove one.
This is not safe practice.

There are other issues in just the design that bother me.
Like using the trigger at all instead of just GroupEnumUnitsInRange() inside the timer callback.
They're not really important for the case you posted on though.

04-24-2007, 12:56 PM

UnMi

Quote:

It leaves a 4 byte temporary reference where the handle once was that goes away when the pointers are nulled.

I see, thanks.

Quote:

I know, but it does not seem to bug even if I do nullify those timers.
When everything else is set to null, the bug seems to be fixed if you just remove the set arrow = null. (Also, if you have a little Wait between the removal of the Arrow and set arrow = null, it won't bug either.)
...
Interesting...
I just removed all the set to nulls besides the set arrow = null one, and it does not bug.
But having all the set to nulls besides the set arrow = null, it won't bug either, at least not after 10 years casting.
Does this mean that having both would just increase the chance of it bugging by a lot? Hmm...

Quote:

You also do not have a triggercondition attached to the trigger, yet you attempt to remove one.
This is not safe practice.

It should though, I did some tests.

Quote:

Like using the trigger at all instead of just GroupEnumUnitsInRange() inside the timer callback.

What I thought was that using dynamic triggers should be way faster than creating a group for loop checking on every timerexpire.