Blizzard on crack? (MB)

[ZugZugZealot]

library Test initializer Init
    private function Init takes nothing returns nothing
        local trigger t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
    endfunction
endlibrary

It ticked up, and that's with setting to null, which means setting the variable to null for handle incrementation is a bleak point. So no matter what you do the handle stack will keep incrementing. But no matter, that's not a memory leak...

 

[Troll-Brain]

No, no, no.
It takes a few time to get reycled, try this :

library Test initializer Init
    private function Init takes nothing returns nothing
        local trigger t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        call TriggerSleepAction(0.)
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        call TriggerSleepAction(0.)
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
        call TriggerSleepAction(0.)
        set t = CreateTrigger()
        call BJDebugMsg( I2S(GetHandleId(t)) )
        call DestroyTrigger(t)
        set t = null
    endfunction
endlibrary

And now use an array variable in order to don't override any variable, and never set to null, yes it leaks an handle reference ...

 

[Artificial]

For ZugZug's "BJs don't need to null!" test:

library LeakTest initializer Init
    globals
        player p = Player(0)
    endglobals
    
    private function TestIt takes nothing returns nothing
        //call DestroyForce(GetForceOfPlayer(p)) // GetForceOfPlayer doesn't null local force f
        local force f = CreateForce()
        call ForceAddPlayer(f, p)
        call DestroyForce(f)
        set f = null
    endfunction
    
    private function Init takes nothing returns nothing
        call TimerStart(CreateTimer(), 0.0001, true, function TestIt)
    endfunction
endlibrary

First try with the script as it is (for e.g. a minute) and watch the memory consumption stay practically constant. Then change the TestIt contents, so the function will be this instead:

//
    private function TestIt takes nothing returns nothing
        call DestroyForce(GetForceOfPlayer(p)) // GetForceOfPlayer doesn't null local force f
        //local force f = CreateForce()
        //call ForceAddPlayer(f, p)
        //call DestroyForce(f)
        //set f = null
    endfunction

Then run it for a minute again, and see the memory consumption run up. At least for me the rate was about 400 kB/s (or sumtin ). Since the only differences between these two are (1) an extra function call and (2) the lack of nulling in the BJ, one of those should be causing the leak. Dunno about you, but I put my money on the second option.

It would be rather stupid from Blizzard to create a different Jass parser/compiler/translator/whatever for just Blizzard.j, don't you think? Not that they wouldn't have done other silly things, but this one would've required additional work from them, which makes it even sillier.

And for the "no matter what you do the handle stack will keep incrementing" test:

library LeakTest initializer Init
    private function TestIt takes nothing returns nothing
        local location l = Location(0, 0)
        call BJDebugMsg(I2S(GetHandleId(l)))
        call RemoveLocation(l)
        set l = null
    endfunction
    
    private function Init takes nothing returns nothing
        call TimerStart(CreateTimer(), 0.1, true, function TestIt)
    endfunction
endlibrary

Test that and see it (surprisingly ) print out the same number every time. Then comment out the [ljass]set l = null[/ljass] line and puff, it will start displaying a new number each time the timer expires.

The handle ids aren't recycled instantly, but a bit later. Perhaps when the thread ends (since that's a natural place for the following code to run), but might also be it's done periodically on a pretty high frequence, as having a 0.001 period for the timer in the previous code will display about 5 different handle ids.

Some of this is already mentioned, but just thought to throw my two cents in. x)