Memory Leak Tracing Help
I'm using VBCC and the Eclipse CDT->GCC chain for dev. Target is 3.1.14. I use MungWall, MuForce, MemMinister, and CodeWatcher.
One weird thing I can't track down is this CodeWatcher output: Code:
The following memory blocks were NOT freed: Is this something I should even be worrying about? Are these maybe being harvested back by the OS at some point after CodeWatcher exits? If this is not "normal", any advice on how to track it down? I've looked at the memory, but I can't tell what it is. I mean, the 10s are pointers to the 248s, but I can't make out what the 248 blocks are. Code:
if ( (global_app->screen_ = OpenScreenTags(NULL, |
What OS version are you using? OS3.0 had problems with the memory system allocator.
|
Have been developing against 3.1.4.
I ran it just now against 3.1 (KS 40), and similar result in code watcher, but the 248 byte items are 292. |
Quote:
|
Thanks for that info Thomas. I replaced mungwall with MuGuardianAngel (http://aminet.net/package/dev/debug/MuGuardianAngl.lha).
|
I finally worked up a minimal testbed for this, because it was bugging me, but I don't know what the results mean.
Test program: all it does is open a window (on a custom screen, or not). you close the window, the program exits First of all, the test results: If I DO open a custom screen, I get these memory leaks: Code:
The following memory blocks were NOT freed: Code:
The following memory blocks were NOT freed: Code:
The following memory blocks were NOT freed: Code:
The following memory blocks were NOT freed: Code:
All allocated memory was freed. I get same leaks when compiling with Bebbo gcc toolchain, as with VBCC. I don't have a native Amiga C compiler, so haven't tested that. here's the test program: Code:
#include <exec/types.h> |
Could this be a false positive on the reporting tools?
I compiled and run your code. Avail reports the same memory free before and after executing your code. No leak. PS: On standard emulated A1200 (if that matters) |
You should not need to #define types. Including exec/types.h should be enough.
|
|
Quick guess:
Your "phantom memory loss" is related to your console history/buffer. EDIT: more time to write now: I can run that example program over and over and the memory reported by `avail` stays constant, but only if I disable the history stuff in KingCon... |
To detect memory leaks, first run SegTracker to be able to find out in which segment/resident module the allocation is located. Then, try something like MemLog (in aminet) which will record all memory allocations. There is a short usage guide included.
|
I have diving into this the last couple of days, since after having added a simple window, with no IDCMP flags, to a program I am currently developing MemLog started reporting a memory leak, like this:
Code:
0x00000028 bytes at 0x07DDD4C8, Stack traceback: CodeWatcher reports something similar. This simple piece of code, also triggers a warning: Code:
#include <proto/graphics.h> To check if it may be a false positive, I checked Intellifont and IconEdit with MemLog and MemLog also reported leaks for those. So, perhaps opening a window on the Workbench screen trigger false positives, as in opening a window always leaks? Perhaps this is documented somewhere. I am also using 3.1.4 and compiling code with m68k-amigaos-gcc (GCC) 6.5.0b 201226214530 (thank you Bebbo!!) |
A pattern I noticed.
MemLog does not report mem leak for my application if I launch it from the info file and open a new shell window to Avail Flush after termination. This also works: 1. Open three shell windows. 2. In the first window run Avail Flush and then MemLog TASKNAME <name of task> 3. In the second window run <task name> 4. When the task stops in the second window close it. 5. Run Avail Flush in the third window and then close it. 6. CTRL-C MemLog. This is not needed if my application does not open a window. |
Note that the task name is the program name as you start it on the shell, case sensitive, potentially with the full path upfront. Thus, if you start your program as "Foo:Bar/bla", the TASKNAME should be exactly that.
If you start a program from workbench, the task name is the name of the icon, case-sensitive. |
@Thomas Richter
Ah, devil is in the details (as always). Indeed specifying the exact path solves the problem. Thanks. (Lol that was a timesink) |
All times are GMT +2. The time now is 17:00. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.