ParamArray causes memory leak

  1. ‹ Older
  2. 3 weeks ago

    Markus R

    Nov 26 Pre-Release Testers, Xojo Pro Europe / Germany
    Edited 3 weeks ago

    @Thomas S method_b new class1
    //class1 DOES NOT destruct here. It survives after following break statement, until the very end of the method
    break

    maybe the scope is more like this, valid inside in method Test, but then i would also expect the same behavior.
    it would be a memory leak if obj is valid/exists outside of the method test and garbage collector had run.

    method Test()
     var obj = new class1
     call method_b obj
     end method
  3. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)
    Edited 3 weeks ago

    @Markus R garbage collector had run.

    Xojo does not have a garbage collector (mark space for future release from a background sweeping process), it uses reference count and releases objects immediately.

    So it probably means that case a got 0 after return, and case b not. Not sure, but it appears a bug (potential leak) due to apparent inconsistency. Maybe a loop of cases b will cause a memory overflow due to not releasing it. It deserves a feedback case in case of such thing occurring.

  4. Markus R

    Nov 26 Pre-Release Testers, Xojo Pro Europe / Germany

    @Rick A So it probably means that case a got 0 after return, and case b not.

    somehow the same meaning reference count or garbage collector.

    It survives after following break statement, until the very end of the method

    i meant it can be correct.

  5. Kem T

    Nov 26 Pre-Release Testers, Xojo Pro, XDC Speakers Connecticut

    This conversation does not have to be in the Pre-Release channel as 2019r.1.1 does the same thing. I suspect it's worked that way for quite some time and nobody noticed.

    It seems like the code is doing something like this for you behind the scenes:

    dim arr() as Class1 = array( new Class1 )
    Method_B arr

    That hidden (for lack of a better description) arr variable is treated like a local variable, so it survives until the end of the block, not the method per se. For example, this will cause immediate destruction:

    if true then
      Method_B new Class1
    end if // boom

    Since Destruction occurs eventually, I'm not sure how this is a "leak"...

  6. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)

    I think method_a causes correctly:

    main:
    Begin
    
       Begin // scope
    
          Var temp1 = New Class1
          call method_a temp1
    
       End // scope
    
    End

    And method_b wrongly:

    main:
    Begin
    
       // Begin // missing implicit scope
    
          Var temp1 = New Class1
          call method_a temp1
    
       // End // missing implicit scope
    
    End
  7. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)

    @Kem T Since Destruction occurs eventually, I'm not sure how this is a "leak"...

    If the created In-Parameter value survives beyond the expected point of release, if it's not a leak, at least is a bug, because the destructor code of the parameter object must run BEFORE the next line, as the implicit scope of such method ended.

  8. Kem T

    Nov 26 Pre-Release Testers, Xojo Pro, XDC Speakers Connecticut

    I agree that it seems like a bug.

  9. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)

    It deserves a review by the engineers.
    So, please open a feedback, and with the arguments there, put a link to this conversation.

  10. Markus R

    Nov 26 Pre-Release Testers, Xojo Pro Europe / Germany

    its like
    scope/scope
    ..something
    endscope/endscope

    or
    scope
    ..something
    endscope

    if it do something behind the scenes (because a paramarray) this scope in scope is not necessary.

  11. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)
    Edited 3 weeks ago

    If the implict scope is right, the release routine of a paramArray have some bug. Technically is a leak, because it escapes its scope.

  12. Thomas S

    is not verified Nov 26 Pre-Release Testers, Xojo Pro

    I'm not sure how this is a "leak"

    I agree.

    'Leak' might not have been the most helpful term for me to use, because the main problem is not to do with memory per se.

    The problem becomes harmful when the object refers to an external resource.

    To illustrate, imagine the following contrived pseudo-code example:

    dim c as new opengl_context(...)
    dim t as new texture
    c.bind t
    c.draw(...)
    t=nil //fire t's destructor which calls glDeleteTexture in context of c
    c=nil //fire destructor which cleans up context

    Above code should work correctly, but crashes if 'bind' takes a paramarray, because 't' outlives c and glDeleteTexture is called after the context has been destroyed.

  13. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)
    Edited 3 weeks ago

    @Thomas S 'Leak' might not have been the most helpful term for me to use, because the main problem is not to do with memory per se.

    A 'Leak' is something escaping its release and destruction scope and "floating around" unexpectedly. I agree it's not a memory leak, but it's a leak. A resource leak. There are more leaks than memory leaks, like handle, objects and resources leaks (most "non-memory" leak (low-level) can be generically said as a resource leak).

  14. Kem T

    Nov 26 Pre-Release Testers, Xojo Pro, XDC Speakers Connecticut

    Workaround: surround the function that uses ParamArray with If True ... End If.

  15. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)

    @Kem T Workaround: surround the function that uses ParamArray with If True ... End If

    Also put it in the manual and be ashamed.

  16. Norman P

    Nov 26 Pre-Release Testers, Xojo Pro under THE bus

    I use forced fake scope levels like that for a bunch of things
    Usually in unit tests so I can keep variable names & such the same and then reuse them when I create a new test

  17. Rick A

    Nov 26 Pre-Release Testers (Brazil. UTC-3:00)
    Edited 3 weeks ago

    @Norman P I use forced fake scope levels like that for a bunch of things

    Me, you, Kem, etc. People reading this today also. But anyone starting tomorrow or never reading this conversation just expect things working, no leaks, events working in the expected sequence, etc. And after suffering "weird" unexpected things and finding this symptom and conversation, the only vendor excuse is pointing in the "known problems" footnote of the ParamArray page a workaround listed there while not fixing it.

    People here acquired the weird culture of "if a workaround exists for us, let's just keep the bug there". It gets on my nerves, and I always fight against this culture... a bit, before giving up.

    I still wish that the OP post a feedback, unless he express he doesn't want to.

  18. Thomas S

    is not verified Nov 27 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    Feedback Case #58427

  19. 2 weeks ago

    Rick A

    Nov 28 Pre-Release Testers (Brazil. UTC-3:00)
    Edited 2 weeks ago

    @Thomas S , they closed one duplicate and set a countdown to close the case without testing because they want you testing it deeper for them. Have a look in the Feedback Case #58443 and say anything there.

  20. Thomas S

    is not verified Nov 28 Pre-Release Testers, Xojo Pro

    Thanks. Example project has now been attached.

or Sign Up to reply!