RE : RE : RE : RE : [fpc-pascal] Is such memory statistics possible?
Attached a patch for the following: - ported to win64 - added a Depth parameter to PMMCollectStat (default 15). When the lcl is build with debug line info, the output from PMMCollectStat is cluthered with LCL functions such as message loop/handling functions. Depth is the maximum stack backtrace used to create the list. Ludo uProcMemdlg.diff Description: Binary data uProcMemMon.diff Description: Binary data uProcMemStat.diff Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Is such memory statistics possible?
On Fri, Aug 19, 2011 at 3:26 PM, Ludo Brands ludo.bra...@free.fr wrote: ** Based on this discussion and the following research I made an attempt to implement something like this for fpc/lazarus. The final result are a couple of units and a dialog that allows to see the results in any time inside the program. You can see the real example in the screenshot: http://www.maxerist.net/downloads/procmemstat_ss.png The download link for pascal sources: http://www.maxerist.net/downloads/procmemstat.zip (5k) Where can I find units uNtSnapshot, uMem32, uUniCompat? Looking at the screenshot, I'm confused. Memory allocated by FreeMem. How should that be interpreted? thanks, Ludo Sorry about that, I uploaded the archive once again with only uNtSnapshot dependency. http://www.maxerist.net/downloads/procmemstat.ziphttp://www.maxerist.net/downloads/procmemstat.zip As for the numbers, they're not supposed to be pieces to be summed. I mentioned utilities for finding space on drive, for example my FindFatFolder (http://www.maxerist.net/main/soft-for-win/find-fat-folder), every reachable folder (also nodes, not only leafs) is used and calculated, if you want to find the eater, you just look from the top to the bottom and wait for 'bingo'. In other words If you see a big number and the name of the function looks like a strange source of such big number (cumulative) you look deeper. For folders it works, but will it work for function I still don't know :) Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : [fpc-pascal] Is such memory statistics possible?
OK compiles now. I tested this with 2 programs but when I include uProcMemMon as the first unit in lpr and define -dPROCMEMMON then they both crash with a sigsegv. Undefine PROCMEMMON and they run fine. I've attached a small testprogram that crashes in bufdataset. Just a small copy paste problem: change line 295 Result := OldMemMgr.GetMem(Size); into Result := OldMemMgr.AllocMem(Size); Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Is such memory statistics possible?
On 15 Aug 2011, at 12:03, Ludo Brands wrote: 100.00% (288,964,608B) (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. -37.20% (107,483,136B) 0x80C7DD3: SYSTEM_FPSYSCALL$LONGINT$LONGINT$$LONGINT (in /home/ludo/lazarus/lazarus) | -37.20% (107,483,136B) 0x80C86DF: SYSTEM_FPMMAP$POINTER$LONGWORD$LONGINT$LONGINT$LONGINT$INT64$$POINTER (in /home/ludo/lazarus/lazarus) | -37.20% (107,483,136B) 0x80DE2EE: SYSTEM_SYSOSALLOC$LONGWORD$$POINTER (in /home/ludo/lazarus/lazarus) Note that if you want to see what part of the memory allocation is due to the program and what part due to internal fragmentation in the memory manager, you should compile with -gv (or add the cmem unit as the first unit to the uses-clause of Lazarus). Then the program will use libc's malloc/free/realloc/..., and Valgrind will be able to track every allocation/deallocation individually. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Is such memory statistics possible?
On Mon, Aug 15, 2011 at 2:03 PM, Ludo Brands ludo.bra...@free.fr wrote: ** if there's a common ancestor allocating something (let's call it NewBlock() and it uses GetMem) and I have many descendants using this method, is there a chance to find the eater amongst these descendants or massif tool will drop all the stats to NewBlock()? Max Here is part of the massif output from lazarus memory usage that shows what you are looking for. The ms_print tool that comes with valgrind does the actual formatting. massif and ms_print both have a threshold value which is the percentage below which they don't report details. This is very helpfull in quickly finding problem areas. Thank, Ludo, I think the other questions (if they appear) will be asked when I really used it on a real project Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : [fpc-pascal] Is such memory statistics possible?
On 15 Aug 2011, at 12:03, Ludo Brands wrote: 100.00% (288,964,608B) (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. -37.20% (107,483,136B) 0x80C7DD3: -SYSTEM_FPSYSCALL$LONGINT$LONGINT$$LONGINT (in /home/ludo/lazarus/lazarus) | -37.20% (107,483,136B) 0x80C86DF: SYSTEM_FPMMAP$POINTER$LONGWORD$LONGINT$LONGINT$LONGINT$INT64$$POINTER (in /home/ludo/lazarus/lazarus) | -37.20% (107,483,136B) 0x80DE2EE: | SYSTEM_SYSOSALLOC$LONGWORD$$POINTER (in /home/ludo/lazarus/lazarus) Note that if you want to see what part of the memory allocation is due to the program and what part due to internal fragmentation in the memory manager, you should compile with -gv (or add the cmem unit as the first unit to the uses-clause of Lazarus). Then the program will use libc's malloc/free/realloc/..., and Valgrind will be able to track every allocation/deallocation individually. Yes, that is what I'm doing lately. This is an older trace I took to illustrate to Max how the memory allocated by custom memory allocators such as SYSTEM_ALLOC_OSCHUNK are split up by the massif tool. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
