|
|
On 6/11/21 6:00 AM, 'pvr...@btinternet.com' via fltk.general
wrote:
My application has a view based on Fl_Tree which displays a
report of the database in the app. Everytime I regenerate the
report with different parameters (or a different database) it
looks like the the Fl_Tree_Item created by Fl_Tree::add() are
not deleted by the Fl_Tree::clear().
I was getting humungous memory leakage problems resulting in
my app building up to several hundreds of MB quite quickly and I
think eventually causing the app to crash. I was getting
spurious crashes that I couldn't resolve. I have resolved the
two largest issues, so the Fl_Tree issue is the last remaining
one. Every time I regenerate the report memory usage increased
by about 1 MB, so it's
not too great an issue, just would like to fix it.
Is it a simple matter starting at the root item and working
my way through the tree and deleting all the branches?
I am using fltk-1.4.0 using a snapshot taken April 2020.
Hmm, I'd say make a small program that does something like what
you're doing,
and try to replicate with that. If you can replicate, post the
code for the small program
so we can try to track down the issue.
Using test/tree I don't see any leaks offhand creating/clearing
20,000 items repeatedly.
To test, I backgrounded "test/tree", then ran the following
to keep an eye on the app's
memory use:
while [[ 1 ]]; do sleep 3; ps u --pid
<<PID_OF_TREE>>; done
then in the test/tree app, repeated these two tests while
watching the VSZ/RSS values
of the above command:
Test just the default tree with 500 items
1) Hit the button: Test Operations -> "Clear All"
2) Hit the button: Test Operations -> "Rebuild
Tree"
3) Goto 1
Test creating/removing the 500 + 20,000 items
1) Click the "ROOT" item (to highlight it)
2) Hit the button: Test Operations -> "Add 20,000"
(creates an additional 20k items at bottom of tree)
3) Hit the button: Test Operations -> "Clear All"
4) Hit the button: Test Operations -> "Rebuild
Tree"
5) Goto 1
When running the second test, you have to wait for memory to
stabilize after the
first iteration.
What should happen is the numbers for VSZ/RSS reach a certain
value, and then don't
keep getting bigger on each iteration. If they did get bigger
each iteration, that'd be a leak.
The numbers will NOT get smaller when you hit the "Clear All"
button, but should not grow
each iteration.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/873b1c78-4626-eb37-18b6-ac8ccb0ce429%40seriss.com.
[ Direct Link to Message ] | |
|
| |