Many memory leaks not in my code lazarus / 12-Debugger ---------------------------------------------------------------------- russdirks · 2017-04-18 04:23 I recently enabled heaptrc for a program I am working on.  I used the project options screen: -gh as well as -gl.  I did not manually add the unit to my code.  I found it very helpful to locate a number of memory leaks.  However, the heap.trc file shows many, many memory leaks that contain no line number information.  Does that mean the leaks are in pascal system code?  Here is the first few entries, after running my program for only 2 minutes. Code: [Select]Heap dump by heaptrc unit 69136 memory blocks allocated : 34568850/34824576 68448 memory blocks freed     : 34527568/34782368 688 unfreed memory blocks : 41282 True heap size : 1474560 True free heap : 1326080 Should be : 1344288 Call trace for block $0000000006A1AF50 size 43   $0000000100011282   $00000001000097F3   $000000010000A84C   $000000010000D91A   $000000010015F750   $000000010015E0D5   $000000010015D353   $BAADF00DBAADF00D Call trace for block $0000000006A2D9F0 size 16   $0000000100011282   $000000010000E427   $000000010015F732   $000000010015E0D5   $000000010015D353   $000000010015D670   $000000010015D397   $BAADF00DBAADF00D Call trace for block $0000000006A2D950 size 16   $0000000100011282   $000000010000E427   $000000010016027A   $000000010015DF6E   $000000010015D4D9   $000000010015D3D9   $000000010015D670   $BAADF00DBAADF00D How can I debug this? ---------------------------------------------------------------------- russdirks · 2017-04-18 05:54 I should  mention I am getting these symptoms on both Windows 10 and OSX ---------------------------------------------------------------------- molly · 2017-04-18 06:06 Quote from: russdirks on April 18, 2017, 06:23:49 amMany memory leaks not in my code That is what they all say  Usually that means you've done something that is buried away and heaptrace was not able to directly trace it back to your code. The trace as shown does not indicate with certainty that it is not directly related to your code. Of course the opposite is also true in that it might be a 3th party class/component that is causing the trace or perhaps you stumbled upon a bug that is present inside rtl. Compile your rtl with debug and gl turned on and you should be able to get a better trace. See also this thread Quote$BAADF00DBAADF00D That isn't something pretty, rather an indication something went seriously wrong as it is a special marker reading "Bad Food" PS: in case the number of unfreed memory blocks goes higher the longer you run your program then think about where in your code you add something to f.i. a (object)list, treelist or similar and you forgot to free the items that you added over time. ---------------------------------------------------------------------- Eugene Loza · 2017-04-18 06:59 Try RUN>CLEAN UP AND BUILD and then run again. Helped me two days before And yes, don't repeat my errors. Always have debug mode on and track memory leaks unless you do a release. It's much easier to fix them as soon as you see them (when you know what exactly you've added/changed), than trying to fix memory leaks in old code (the exact thing I've been doing at weekends ) ---------------------------------------------------------------------- Thaddy · 2017-04-18 09:18 Quote$BAADF00DBAADF00D That's called a marker..., like the more commonly known $DEADBEEF.  It's just more friendly to vegetarians. (or not.., I like dead beef.) . In effect it tells you your code s*cks. $FADFED Anyway: in gdb: go to the address, set a break point there, you know what leaks. People who can't debug should refrain from programming. Hmm, can anybody think of anything better to insult - slightly - within the constraints of A..F? (DEADDAD doesn't count)) ---------------------------------------------------------------------- MathMan · 2017-04-18 12:42 Quote from: Thaddy on April 18, 2017, 11:18:00 amQuote$BAADF00DBAADF00D That's called a marker..., like the more commonly known $DEADBEEF.  It's just more friendly to vegetarians. (or not.., I like dead beef.) ... Hmm, can anybody think of anything better to insult - slightly - within the constraints of A..F? (DEADDAD doesn't count)) Hi Thaddy - how about "BADDEED5"? - ok it's not 100% in A..F but 5 is similar enough to S I'd say ... ---------------------------------------------------------------------- Leledumbo · 2017-04-18 12:44 The leak doesn't always lie your code, but the way your code uses the RTL/FCL/whatever that's compiled without debug info. In that case, the best the RTL can do is to print the stack traces only. @Thaddy: Grab from https://en.wikipedia.org/wiki/Hexspeak ---------------------------------------------------------------------- russdirks · 2017-04-18 16:11 Quote from: molly on April 18, 2017, 08:06:51 amQuote from: russdirks on April 18, 2017, 06:23:49 amMany memory leaks not in my code That is what they all say  Yeah, I probably shouldn't have been so confident.  I may have to eat my words.  But that's a lot better than eating $BAADF00DBAADF00D!    (Sorry, couldn't resist) QuoteCompile your rtl with debug and gl turned on and you should be able to get a better trace. Recompiling right now, using the "Build Lazarus : Debug IDE" profile which I assume is how you do what you are referring to. ---------------------------------------------------------------------- russdirks · 2017-04-18 16:27 QuoteRecompiling right now, using the "Build Lazarus : Debug IDE" profile which I assume is how you do what you are referring to. Ok, that didn't work.  I'm still not getting line numbers in the stack traces.  How exactly do I "Compile the rtl with debug and gl turned on"? ---------------------------------------------------------------------- russdirks · 2017-04-18 17:06 Ok, I found the problem, the old fashioned way ... going through my code line by line. ---------------------------------------------------------------------- balazsszekely · 2017-04-18 17:15 You most likely use some kind of composite array/list in your program.  Just before you free the list make sure you also free every object(s) belonging to each item. You need some kind of Finalize(Data) where Data is a pointer.  I'm I right? ---------------------------------------------------------------------- Martin_fr · 2017-04-18 17:15 Just a quick note: Not sure what OS and which version of fpc you use. But there was some report that fpc 3.0.2 has a regression on Linux (not sure 32 or 64 bit or even both?). In some cases line numbers are not shown, despite the compiler setting used, would normally show them. Check the mailinglist and/or the bugtracker ---------------------------------------------------------------------- russdirks · 2017-04-18 17:20 Quote from: GetMem on April 18, 2017, 07:15:16 pmYou most likely use some kind of composite array/list in your program.  Just before you free the list make sure you also free every object(s) belonging to each item. You need some kind of Finalize(Data) where Data is a pointer.  I'm I right? No, actually it was the GetJSON function.  It converts a JSON string to an object, which you are responsible to free, but I wasn't doing that.  The documentation should really say something about that, although it is kind of obvious. ---------------------------------------------------------------------- molly · 2017-04-19 08:43 Quote from: russdirks on April 18, 2017, 06:27:46 pmQuoteRecompiling right now, using the "Build Lazarus : Debug IDE" profile which I assume is how you do what you are referring to. Ok, that didn't work.  I'm still not getting line numbers in the stack traces.  How exactly do I "Compile the rtl with debug and gl turned on"? Compiling the IDE in DEBUG mode should do the trick. However, do note the remark made by Martin_fr. I was not aware, so apologies. On the other hand you was very vague with mentioning target, versions and what code was causing you issues. QuoteNo, actually it was the GetJSON function.  It converts a JSON string to an object, which you are responsible to free, but I wasn't doing that.  The documentation should really say something about that, although it is kind of obvious. Ah, yes. GetJSon will do that for you. Indeed obvious but something easily overlooked. Glad you where able to locate the culprit. It is usually a pita to find something like that back when your project has grown to substantial size and offending code is tucked away deep inside your project.