These are useful additions, thanks. I suppose the limit automatically solves the problem of first winners whose are not usable in real life. That's the purpose of the limit. In a lot of gui programs, actions, and thus memory allocations, are triggered by events (button/menu clicks, callback functions for all kind of window updates,...). So there are always a lot of message related functions on the stack. Since the unit records only addresses in the main program, all OS / graphics related functions aren't shown and interpreting the stack can be really challenging. IMO, a big improvement would be to unwind the stack instead of checking every value found on the stack. This would avoid false positives caused by random data falling in the main address range or by passing function addresses as a parameter. You could then even drop the check against the main program address range and include dynamically loaded libraries. Downside of unwinding a stack is that it becomes difficult when stack frames are omitted. But for debugging purposes, forcing stack frames is always a good thing. I tried to use it with Lazarus (with opening 150 files afterwards) and the results were bad in terms of the speed, 30 minutes just to start and a couple hours to work (1.7 Ghz Celeron), obviously something like hash table is needed. Also showing the number of memory requests for particular function overall can be also useful, it could add more sense to some puzzling entries. A hashtable for MonBlocks and AddrList will help a lot. Keeping AddrList and FuncNames outside PMMCollectStat would also help for subsequent uses. The number of requests is something I'm also missing most in the valgrind massif tool. You get a detailled stack of the memory allocations but you need to check the code at all levels to check where there are loops and figure out the count of the loops. 10M allocated by a function executed 10000 times or 10 times changes a lot when trying to find memory "eaters". As for lazarus results, some entries are still unexplained to me (the first ~300 are in the attachment) [ 19,832,531 ] TMAINIDE__DOOPENEDITORFILE [ 19,801,582 ] TWIN32WIDGETSET__SETFOREGROUNDWINDOW the code inside is only Windows.SetForegroundWindow(HWnd), but maybe windows forces sending message to the tab and this forces the tab (synedit) to make postponed operations. It's the only explanation I have currently ... [ 19,749,554 ] GETWIN32WINDOWINFO ...no explanation [ 19,686,289 ] CLEANANDEXPANDFILENAME ...no explanation [ 14,367,684 ] FILEGETATTRUTF8 ...no explanation Possibly those were false positives i.e. some numbers on the stack that falls into usable range, but actually is something else. Where these results obtained with or withouth the Depth patch? Max
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
