Heaptrc & Memory Leak ???? lazarus / 12-Debugger ---------------------------------------------------------------------- warcode · 2012-02-29 15:33 Hi all First off i try to find some memory leak in a custum package i'm using, i have follow this guide (http://wiki.lazarus.freepascal.org/Debugger_Setup) for setup the debugger. I'm using lazarus (snapshot svn 35620) 0.9.31 and fpc 2.6.1  on a windows7 64 bit. My main trouble is that when i close my application that i wanna debug i always get a error SIGSEGV and after this  a Assembleur windows popup with asm stuff (realy not usefull for debugging or spot memory leak)  This is a sample output of the assembleur windows 0042CA10 8b4004                   mov    0x4(%eax),%eax 0042CA13 e808f9ffff               call   0x42c320 0042CA18 c3                       ret    0042CA19 0000                     add    %al,(%eax) 0042CA1B 0000                     add    %al,(%eax) 0042CA1D 0000                     add    %al,(%eax) 0042CA1F 00                       add    %al,0x1c8908ec(%ebx) CLASSES_TLIST_$__INSERT$LONGINT$POINTER 0042CA20 83ec08                   sub    $0x8,%esp 0042CA23 891c24                   mov    %ebx,(%esp) 0042CA26 89742404                 mov    %esi,0x4(%esp) 0042CA2A 89c3                     mov    %eax,%ebx 0042CA2C 8b4304                   mov    0x4(%ebx),%eax 0042CA2F 89ce                     mov    %ecx,%esi 0042CA31 e88af9ffff               call   0x42c3c0 0042CA36 85f6                     test   %esi,%esi 0042CA38 740e                     je     0x42ca48 0042CA3A 89f2                     mov    %esi,%edx 0042CA3C 89d8                     mov    %ebx,%eax 0042CA3E b900000000               mov    $0x0,%ecx 0042CA43 8b1b                     mov    (%ebx),%ebx 0042CA45 ff5368                   call   *0x68(%ebx) 0042CA48 8b1c24                   mov    (%esp),%ebx 0042CA4B 8b742404                 mov    0x4(%esp),%esi So my question is how to using/working with the dam Heaptrc  (-gl -gh) for find mem leak i wanna see the line code when the mem are assigned and not correcly free Thank for any help ---------------------------------------------------------------------- Martin_fr · 2012-02-29 18:15 Well, getting an SigSegV (in some list) may well be the reason of a mem leak. TFPList is part of fpc, so it does not have debug info (you can rebuild fpc, if that is really needed.) Though in your case it actually has some, but apparently not enough to finhd the source for this file. If you open the callstack window, what does in show? HeapTrc reports when your app exits. But when a crash closes dows your app, heaptrc might not get the chance. So you first need to find the reason for this crash. It likely is not in TFPList, but in the calling code. So try the callstack. SigSegV usually means invalid mem access. So maybe you access an object that was freed before? Look for 0x0 in the calling arguments of each function ---------------------------------------------------------------------- Laksen · 2012-02-29 18:39 Sounds more like the TList that caused the exception wasn't allocated, since it fails in an insert procedure ---------------------------------------------------------------------- warcode · 2012-02-29 19:36 Hi i get ride of the SIGSEGV (a tlist that try to free before assigned) But i have a other trouble with debugging. i have a custom tlistbox like control that i need to regenerate on the user demand, the trouble is that this tlistbox can have 5000 item and more and don't look to free memory correctly. i'm using process explorer for check the memory and when i add 5000 item, the memory are allocated but if i do a clean or free on my custom listbox the memory don't return back to what i have before insert 5000 items... i dont wanna got a out of memory error because my application need to run 24/24h thanks for help ---------------------------------------------------------------------- Martin_fr · 2012-02-29 20:32 First of all, process explorer  is no good measurement. FPC gets chunks of memory from the OS, and when your app needs memory it gets some of that, if your app frees memory, it goes back to that pool and will be re used. But the OS will not know that. Anyway, if you compile with heaptrc, then you should now get a message, when you close the app. You should get the message always, even if there was no leak. It is displayed as one or more dialogs. There is a way to set the environment, and log to a file. Or compile as console app -WC (uncheck -WG). But then you must ensure the console will stay open. So you open a windows command-line, and start your app from there. If you get no output at all about memory, then we need to check that heaptrc is indeed used. If you get output, then it should have filenames and linenumbers, otherwise make sure to rebuild *all* with debug info. In Lazarus install the "leakview" package. It adds itself with an entry in the tool menu. Copy and paste the stack-traces by that you got from heaptrc, and you can navigate by double click. Note, that if you have an object that is not freed, then memory held by that object is neither freed (including sometimes strings), so you need to go through all the traces and find the one that created the object.