Hi, I need a cranial reboot... .44 caliber. thanks again for your help. Marty
marty moore <[EMAIL PROTECTED]> wrote: HI, Wow! Great information. Imm, that link had a good description. Greg, I'll look into the core dump. I've never looked at one before. My current issue, now that I've regained my sanity(????), is a valueinput widget called new_lay. Everytime the program executes 'new_lay->show(), the memory leak in valgrind increases 100 bytes. It would seem that this is a bloating issue that I should investigate, since it is likely to be called multiple times during normal program use. Thanks for all the help. Marty Greg Ercolano wrote: imm wrote: > On 28 Nov 2007, at 20:50, marty moore wrote: > >> Didn't realize I was in the presence of a lore master..... > > Not me. But there are some around here... > > >> What is the best way to make sure my code is clean? > > Valgrind is very useful, but you just need to understand what it is > telling you. Which isn't easy sometimes. Or most of the time, in my > experience! Agreed; valgrind, purify, insure++ and the like are all very handy tools, but they will tell you about 90% crap that you really don't want to know about *unless you've heavily tuned your program down for such purposes) "Memory leaks" that you should care about are cumulative, where the program gets bigger and bigger when it shouldn't, causing it to bloat over time. Good leak checkers will warn you when allocated pointers get dropped or overwritten, such that the app has no possible way to free the memory location because there's no longer a record of it in any pointer. Not all checkers look for this, as it's time consuming at runtime. In some cases it's useful to try to identify blocks of memory that have accumulated by terminating the program and seeing what's still allocated, but you often have to ignore a lot of stuff, as often operating system and c/c++ library calls leave small amounts of memory allocated (cout/cin) (or sometimes there are bugs in these calls) as well as window managers, libraries, etc. Sometimes it's useful to let the app bloat, then coredump it, and look at the core to inspect the memory to see what data has bloated it. Often you can identify the repeating contents of the core, which is often the largest part of the dump due to bloat. Then you sniff around in your app to see where that data is managed, and look for places it's leaking. I can recommend 'insure++' for finding such things.. I've used that tool a lot over the years, and although not cheap, and VERY slow, it's worth it. I've often had to wait 10 minutes for an app to just start running, which normally takes under a second. You never have to worry about memory still being allocated after your program has exited; a common misconception. If that were the case, we'd be rebooting 50 times a day! ;) _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk --------------------------------- Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk --------------------------------- Never miss a thing. Make Yahoo your homepage. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
