In my current project, I download pdf files.
I had fun adding an ImageViewer to display it, and then save it.
I had macOS Tahoe reporting no available memory after around 1,000 downloads (depends on the pdf size, I suppose.
After some days, I finished to comment the line:
ImageViewer1.Image = p // p is a MemoryBlock with the pdf
It was a week ago. I never had troubles with missing available memory.
So, I can say “the ImageViewer is leaking”.
Did you make a sample project?
Is this desktop or web project?
How did you manage to assign a memoryblock to a property, that needs a picture?
Do you know about the user of NSAutoreleasePools on macOS?
Memory is release later, when the application is no longer busy.
What for ?
The only time the control is used is in the line I shared above. Here it is again:
ImageViewer1.Image = p
In case you read the thread too fast, this line is in a Loop where p (a MemoryBlock) is populated with a pdf on macOS Tahoe. Current Xojo (no beta).
I deleted the ImageViewer to be sure I do not reference it elsewhere (in 30 lines ?)
In this case, sharing a sample project = sharing the whole project (the whole project is around 30 lines of code)
Var p As Picture = Picture.FromData(content)
content is a MemoryBlock.
As you are working using a loop, you need to do something to release memory as all the memory is used before your application is no longer busy for the OS to clear it.
Because
A. We’d like to see it
B. If it is really leaking , you’ll need a project to file a bug
I understand. But when I remove the use of the ImageViewer (the line shared), the leak disappears. Thus my conclusion.
BTW: I declared and cleared the MemoryBox and the URLConnection in the Loop first, then I commented the line that use the ImageViewer.
Now, if you are sure the leak can’t be from the ImageViewer I will be happy to share the project (< 30 lines in a Button).
Your app should not load load a ton of images in a tight loop.
Consider using a timer to load one every second.
I wonder if this is related:
I didn’t say it wasn’t imageviewer, but just saying something is and then offering no proof and no way for others to test it exactly as you’ve done it means we can’t help prove it one way or the other.
We’re just trying to help or help corroborate your findings. If you didn’t want that, just say so.
I would like to point out that the original code and this code is the reason we were questioning things. You said twice that p was a memoryblock. Since you can’t assign a memoryblock directly to an Imageviewer, we wanted to see the code. It was only later that you said that you were loading the memoryblock into a picture first.
I am at 3,280 downloaded pdf files and the SSD have only 8GB of free rooms… usually, I have to reboot at less than 1,000 files and around 10/12 GB of free rooms in the SSD.
As I wrote earlier, once i stopped using the ImageViewer, there was no more memory leak.
Sorry for that, I think that I demonstrate where the leak is and do not think it mattered to know from where the picture comes (I saved p using a BinaryStream to disk as pdf file) matters in any way.
To be crystal clear, p is still saved to disk, so the leak does not comes from the MemoryBlock nor from the URLConnection.
Of course, I can be wrong and get an erroneous conclusion.