On 28 Jul 2007, at 16:52, Benjamin Stauffer wrote: > This example demonstrates the leak perfectly.
OK, I'll try and take a look at that later on... In the meantime, a few questions (and note I haven't tried your example yet so bear with me!) > The report given by the detector is: Leaked object at 003F4D98 > (size 192, 00406EF6) > > The leak is 192 bytes each time the program is run. It does not > grow as the program stays open. Hmmm, if I understand you correctly, you say the program reports a leak of 192 bytes for every run of the program, no matter how long it runs for, or how many times the [add|repeat]_timeout is called? In that case, I suspect that what you are seeing is a false positive from the detector (indeed, I'm surprised the fltk code doesn't trigger more examples than that.) The fltk code has many functions and objects that dynamically allocate memory resources when they are first used, that is not explicitly released - rather it is retained by the fltk core and reused the next time you create an item of the same type (if the previous item no longer exists, or course.) This is usually done for "system" like things, such as timers, that are likely to be reused and are likely to persist for the runtime life of the program. But that's not a leak, since the usage does not grow over time, and the operating system guarantees to reap all memory allocated to your application when it exits. Rather, this is a design decision, an optimisation for "Fast and Light", as in FLtk... A little anecdote that might illuminate this (I hope!): We had a huge c++ app, and a guy was tasked with maintaining it, he was pretty much fresh out of university... Now, he put in a lot of good enhancements, but people started to complain that it was taking a long time to quit. Turned out he'd been through the code and (because this was what he was taught in school) added explicit calls to delete *everything* that had been dynamically allocated at runtime - even for all the objects that persisted for the entire lifetime of the program (which was practically everything). The result was that when you quit the program, you had to wait for all the objects to be deleted, and it was literally taking 5 minutes or more to do. With the delete calls (for the long-life items) commented out, the program quit instantly, and it was trivial to show that the o/s was reaping back all the allocated memory correctly so there was no leakage... fltk implements a similar philosophy of allowing the o/s to reap memory and resources for items that are only destroyed at program exit, rather than explicitly destroying them... I suspect (for now!) this is what you are seeing in your program. HTH -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
