Fixed leaking NSWindows in the Cocoa framework

can anybody confirm the leaking has been fixed?
From what I see, opening a second, third window (even void windows), the average 1 Mega doesn’t get released closing those windows.

34956 Framework » Macintosh (Cocoa) Fixed leaking NSWindows in the Cocoa framework.

I tried to follow where you alerady talk about “void windows”, but do not explain. What is a “void window” ?

Sorry, Michel. May be I should have used “empty window”. Anyway, by “void window” I mean a window with no objects, methods, or properties. In fact, one could argue that a window’s memory does not get released because of possible circular references.

The test I did is very simple:

  1. In a new project, add a button; action handler:
  2. add a second window (window2), setting it as not visible.
  3. Run the project: clicking the button, window2 pops up. Close window2. Continue clicking the button and closing window2.

In Activity Monitor, each time windows2 pops up, the memory of the app increases by about 1 Mega; yet, closing window2 memory should decrease.

Thank you for confirming my test.
Unfortunatelly I do not know how to reopen feedback 34956.

Apparently, the 1 Meg per window is not released.

I downloaded Ulrich project and applied the declare to release, it does not prevent memory for creeping up, probably because the rapid cycle prevents memory management to work.

However, opening and closing windows with buttons it does release memory. So the declare works, but apparently the issue is not resolved at the Xojo level.

Thank you for confirming the issue.
And yes, Ulrich’s workaround is still needed to get memory back to normal.

I just sent a project. Let us see.

Since feedback 34956 is still marked as “fixed”, I opened a new case: 43484, which at present is marked as “verified”.
Anybody eager to put a vote to it in order to see it quickly fixed?

How odd that I’ve never noticed this before, but the project shows it clearly. The memory is leaked whether you use an implicit instance (as in the project) or create an instance explicitly.

The Mac fix posted seems to work, but is this true in Windows too?

The leak does not exist in Windows 10 with 2016R1.

@Kem Tekinay And what about 42044? (Closing a window containing pagepanel does not release memory usage).
For this I don’t think there is any fix/workaround.
So, please, another vote. Thanks.

Ulrich workaround seems to release memory.

@Michel Bujardet I’d be happy to see it, but alas, I see the the same memory-increase. Joe said that the cause is different from 34956, may be that’s why in my tests Ulrich workaround does not work.

What I see is memory going up from 9.4 to 12.6 or so, then after closing the window, it comes back to 11.2. So it is not perfect but it does help greatly.

Yes, I’m happy to agree that in 16v1 the increase is less dramatic that in 15v4. Now, it seems that after the first “jump” the memory gets released in a better way. In 15v4 it would always increase.