Listbox seems to leak a lot of memory on Windows when the parent window is resized.
This seems too big to be true but I verified it on Windows 10 and 7, both on VMWare and on a Surface Pro 3.
Simple steps to reproduce:
Create blank project
Add an empty listbox
Activate locking of listbox on every side
Run the app
Live resize the window continuously for a few seconds: you can see memory grow in task manager
I just opened a (https://xojo.com/issue/42165)]feedback case (42165) for this. Xojo team please take a look at this as soon as possible as it may cause an application to run out of memory after a few hours of normal usage.
I have an app that uses multiple Listboxes via a TabPanel set up the same way. Users including myself are experiencing OutOfMemory Exceptions at completely random times. Now I know what is causing it. Time for Xojo to fix it.
Windows version 2015R4 is completely unusable, that’s clear to me since it seems to explode in memory. I had to go back to 2015R3.1 because I cannot live with at least 5 crashes a day.
After reading some Feedback reports about this issues it’s not clear to me if we just talk about IDE issue or do we have a framework-issue too.
Just speculating, but is it possible this is a result of Xojo adding more visible columns to Listbox? Same here, I am staying on 2015r3.1 for the time being.
[quote=242827:@Markus Winter]A future version or a 4.1 release?
Bugs like this one make a version unusable and should be fixed ASAP.[/quote]
That, and those reports with all those bugs with integers. Who doesn’t use an integer in their app? I’m scared as hell to release anything right now with these releases until those and the memory leaks (listbox and exceptions) are addressed. They’ll get there soon though, I hope.
[quote=242858:@Norman Palardy]report #'s ?
Or are you referring to 64 bit apps ?[/quote]
Specifically:
42278 - For / Loop fails to stop when uInt8 datatype is used (that is actually the case if uInt16 and byte is also used)
42220 - MOD incorrect when numerator is uInt32 and larger than int32
Those are just two, and I know there are more out there. You can argue it’s a function bug, but since I don’t know what’s going on at your end… I’m going to assume it’s an integer-related issue; otherwise, they are both either a simple routine or math function. What’s holding these two up? (While the MOD one is new, I know the 42278 has been an issue for awhile, and is in the feedback under another case somewhere). These two are a issues regardless if 32-bit or 64-bit build. So…
Need me to go on specifics about the exception leaks too? Those wouldn’t normally be an issue; however, some classes and objects rely on them for conditional outcomes (ie. connecting to database failing, etc.). If the application is used as a server, those exceptions can add up pretty quickly. Xojo.Core.Date.Now also has a substantial memory leak where the object is never destroyed after each call (though using the old framework is a work-around).
All these are things that I, and probably many other, use every day… with every application. I understand the importance of knocking out all you can; however, after seeing some minor feedback submissions get entered under the ‘newest’ and ‘recently active’ and then get ‘fixed’ THAT DAY (more so within a day or two)… I’m starting to wonder what warrants whether a bug is severe enough to get addressed? Is it by the amount of work that needs to be done to fix it?
JUST FYI
42278 - duplicate of 41294
definitely not new
present in 2007r4, 2008r5 and has likely been present since the day the sized types were introduced
basically no one found or reported this for 6 or 7 years after it was present
42220 - same as 42278
its present in every old version I tried from 2007 on
These bugs are, I suspect, a result of adding the sized types and are not NEW despite the reports being “new”
The exception leak is new as far as I know
[quote=242874:@Eric Brown]
All these are things that I, and probably many other, use every day… with every application. I understand the importance of knocking out all you can; however, after seeing some minor feedback submissions get entered under the ‘newest’ and ‘recently active’ and then get ‘fixed’ THAT DAY (more so within a day or two)… I’m starting to wonder what warrants whether a bug is severe enough to get addressed? Is it by the amount of work that needs to be done to fix it?[/quote]
It depends on what area its in as different engineers have different areas of focus, what the scope of impact of such a change is, how likely it is to break existing code and many other factors
I know I’ve fixed a few that have come in and been easy to fix so they got knocked out right away
And there are some, one in particular, that Joe & I have been actively working on for more than 6 months
So yes the scope of work involved can affect how quickly it gets done
Gotcha… thanks for the clarification. Not sure if you can answer this or not; however, is it safe to assume integers themselves are being reflected accurately, and those bugs are just a problem in the how those functions work? The for/next bug got me awhile back… and it took way too much of my time to figure out what was going on. I’m just afraid, especially with all the 32-bit vs 64-bit integer confusions, to release something that relies heavily on these integers… only for the results to be broken.
EDIT: And sorry for hijacking the thread. This will be my last question/statement on the issue. I know the Listbox is in dire need of looking into also.
Yes there are issues in 32 bit apps handling of some sized types but they are NOT new - some are really old
If you weren’t worried before I would not be worried now - we haven’t really changed things there
So if you never ran into issues before you’re unlikely to now
For 64 bit because everything is new it may have bugs we have not yet fixed or not yet uncovered despite our best efforts
My experience so far is that things just work - with a few small bumps
YMMV
The loop bug is in the compiler’s code generation of DownTo loops when the induction variable is unsigned. The Mod issue is also related to the compiler’s code generation of the Mod operator, but I have not investigated the case enough to give much detail.
I have the exact same problem with 2015R4.
It happens for both 32 and 64 bits apps on Windows.
A small empty app as described by Angelo is about 5 MB at launch.
Resize the window a few times and the app allocated memory is now 500 MB.
If you continue, you easily reach 2GB… and the add does absolutely nothing.
At that point, it is not a leak but a flood.
I tried with 2015R3.1 and the leak does not happen (very fortunately).
But I have the feeling that this is not the only leak source.
With 2015R4, opening multiple windows and closing them was adding many 10s of MB to the used memory of the app.
The last release of Xojo needs massive fixes on memory management.
I also noticed that if you have ListBoxes in a tab panel, switching between tabs adds about 1.7MB each time (with the same kind of simple empty test app as described initially).
ListBoxes are not only leaking memory on resize…
