English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 17 October 2020, 17:16   #1
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
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:
 Addr: $5A270 Size: 248 RtnAddr: $F8EA6E Hunk: ROM Space Ofst: None
 Addr: $3BF6F8 Size: 10 RtnAddr: $F8EA44 Hunk: ROM Space Ofst: None
 Addr: $2C250 Size: 248 RtnAddr: $F8E9AC Hunk: ROM Space Ofst: None
 Addr: $36B038 Size: 10 RtnAddr: $F8E986 Hunk: ROM Space Ofst: None
This happens in all the apps I write (ok, that's a small number! . I can trim down an app to just the OpenScreen, and it happens. No open screen, it doesn't happen. I'm doing CloseScreen at the end of course. If I run an app 4 times in a row, it often (but not always) uses the same 4 RAM addresses, which seems odd to me if they really weren't being 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,
			SA_Depth,         the_depth,
			SA_LikeWorkbench, TRUE,
			SA_Interleaved,   TRUE,
			SA_Title,         the_title,
			TAG_DONE)) == NULL)
Warty is offline  
Old 17 October 2020, 17:20   #2
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 46
Posts: 1,626
Send a message via Yahoo to Samurai_Crow
What OS version are you using? OS3.0 had problems with the memory system allocator.
Samurai_Crow is offline  
Old 17 October 2020, 17:59   #3
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
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.

Last edited by Warty; 17 October 2020 at 18:00. Reason: (keep typing 3.1.14 when I mean 3.1.4)
Warty is offline  
Old 17 October 2020, 18:49   #4
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 991
Quote:
Originally Posted by Warty View Post
I'm using VBCC and the Eclipse CDT->GCC chain for dev. Target is 3.1.14. I use MungWall, MuForce, MemMinister, and CodeWatcher.
Please do not use MungWall any more. This program has a workaround for a layers.library issue that is no longer existing, and just creates problems on any kickstart more modern than 3.0. Replace by Wipeout or by MuGA.
Thomas Richter is online now  
Old 17 October 2020, 19:43   #5
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
Thanks for that info Thomas. I replaced mungwall with MuGuardianAngel (http://aminet.net/package/dev/debug/MuGuardianAngl.lha).
Warty is offline  
Old 07 December 2020, 07:25   #6
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
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:
 Addr: $54280  Size: 248  RtnAddr: $F8EA6E  Hunk: ROM Space  Ofst: None
 Addr: $42ED40  Size: 10  RtnAddr: $F8EA44  Hunk: ROM Space  Ofst: None
 Addr: $54110  Size: 248  RtnAddr: $F8E9AC  Hunk: ROM Space  Ofst: None
 Addr: $3F4960  Size: 10  RtnAddr: $F8E986  Hunk: ROM Space  Ofst: None
If I do NOT open a custom screen, I get the following memory leaks reported:
Code:
The following memory blocks were NOT freed:
 Addr: $3A9600  Size: 40  RtnAddr: $FB4C46  Hunk: ROM Space  Ofst: None
 Addr: $3EE830  Size: 40  RtnAddr: $FB4C46  Hunk: ROM Space  Ofst: None
 Addr: $3ECDE0  Size: 40  RtnAddr: $FB4C46  Hunk: ROM Space  Ofst: None
If I do NOT open a custom screen, and remove the WA_SizeGadget, the leak goes down to this::
Code:
The following memory blocks were NOT freed:
 Addr: $42AB60  Size: 40  RtnAddr: $FB4C46  Hunk: ROM Space  Ofst: None
If I do NOT open a custom screen, keep the WA_SizeGadget, but remove the Mouse Move IDCMP tag, the leak is:
Code:
The following memory blocks were NOT freed:
 Addr: $42EB50  Size: 40  RtnAddr: $FB4C46  Hunk: ROM Space  Ofst: None
If I do NOT open a custom screen, and further remove the window open tag for WA_SizeGadget, and the tag for ICDMP mouse move, the memory leaks disappear:
Code:
All allocated memory was freed.
Why is there a memory leak from opening the screen? Why, if I comment out the open screen code, do I get those little leaks around the resize gadget and/or mousemove?

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>
#include <intuition/intuition.h>
#include <intuition/intuitionbase.h>
#include <intuition/screens.h>
#include <clib/intuition_protos.h>
#include <clib/exec_protos.h>
#include <pragmas/intuition_pragmas.h>

#define MINVERSION  40

#define BOOL     unsigned char
#define ULONG    unsigned long
#define WORD     short
#define UWORD	 unsigned short

struct Library        *IntuitionBase;

/******************/


int main(void)
{
	struct Screen        *screen;
	struct Window        *window;
	struct IntuiMessage  *intuiMsg;
	BOOL                  quit;
	WORD                  i;

    if (IntuitionBase      = OpenLibrary("intuition.library", MINVERSION))
    {
        if (screen = OpenScreenTags(NULL,
			SA_Depth,         4,
			SA_LikeWorkbench, TRUE,
			SA_Title,         "Leak Test",
			TAG_DONE))
        {
			if (window = OpenWindowTags(NULL,
				WA_Height,       200,
				WA_Width,        400,
				WA_CustomScreen, screen,
				WA_IDCMP,        IDCMP_CLOSEWINDOW | IDCMP_MOUSEMOVE,
				WA_SizeGadget,   TRUE,
				WA_DragBar,      TRUE,
				WA_CloseGadget,  TRUE,
				WA_Activate,     TRUE,
				TAG_DONE))
			{
				quit = FALSE;
				while (!quit)
				{
					WaitPort(window->UserPort);
					intuiMsg = (struct IntuiMessage *)GetMsg(window->UserPort);

					switch (intuiMsg->Class)
					{
						case IDCMP_CLOSEWINDOW: quit = TRUE;
												break;

					}

					ReplyMsg((struct Message *)intuiMsg);
				}

				CloseWindow(window);
			}

            CloseScreen(screen);
        }

        CloseLibrary(IntuitionBase);
    }

    return 0;
}
Warty is offline  
Old 07 December 2020, 08:19   #7
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 50
Posts: 578
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)

Last edited by alkis; 07 December 2020 at 08:23. Reason: added the PS
alkis is offline  
Old 07 December 2020, 09:08   #8
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 40
Posts: 598
You should not need to #define types. Including exec/types.h should be enough.
patrik is offline  
Old 01 February 2021, 16:28   #9
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 867
Hi!

You could also use fortify, it's great at reporting unfreed memory, overwrites, etc.

Cheers!
tygre is offline  
Old 01 February 2021, 17:52   #10
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 498
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...
bebbo is offline  
Old 01 February 2021, 21:18   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 991
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.
Thomas Richter is online now  
Old 18 February 2021, 23:31   #12
edmayn
Registered User

 
Join Date: May 2017
Location: Silkeborg/Denmark
Posts: 21
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:
	0x07930E70 0x078083E0 0x00000028 0x07930EB8 0x07EB9A82 0x07931CD8 0x07F1AE00 0x07811090
	0x07931CA2 0x078D1DB8 0x07930D5C 0x07F1B0F0 0x07811090 0x078D1DB8 0x07930DD2 0x00000000
	0x078D1DB8 0x07DEB1B8 0x01F7078D 0x1DB80000 0x078D1DB8 0x07DEB1B8 0x078D1DB8 0x07EB99A0
	0x07930A46 0x00000000 0x07E220B4 0x07DEB1B8 0x078083E0 0x07E6C8B0 0x07EB99B0 0x07930910
	0x0780A12C 0x078D1DB8 0x07EB99E0 0x07916162 0x01F7843B 0x00000000 0x07E220B4 0x0780A12C
	0x07EB9B10 0x07EB9A88 0x078083E0 0x00000000 0x07DEB1B8 0x078083E0 0x00FE6FD4 0x0780A12C
	0x00FD62AC 0x00000000 0x07DEB1B8 0x00FD53B0 0x07E220B4 0x07E220B4 0x0780A12C 0x00FD60E8
	0x07EB9B10 0x00FD69D2 0x0000000E 0x07E220B4 0x07EB9A4C 0x0780A12C 0x00FD5074 0x00FD4F94
0x00009BAF bytes required in total, 0x00000028 not yet released.
The window is closed with "CloseWindow()".

CodeWatcher reports something similar.

This simple piece of code, also triggers a warning:
Code:
#include <proto/graphics.h>
#include <proto/intuition.h>
#include <proto/dos.h>

int main(void)
{
	struct TagItem tagitem[8];
	struct Window *window;
	unsigned long ilock = LockIBase(0L);
	struct Screen *screen = LockPubScreen(NULL);

        tagitem[0].ti_Tag = WA_Width;
        tagitem[0].ti_Data = 500;
        tagitem[1].ti_Tag = WA_Height;
        tagitem[1].ti_Data = 300;
        tagitem[2].ti_Tag = WA_Top;
        tagitem[2].ti_Data = 400;
        tagitem[3].ti_Tag = WA_Left;
        tagitem[3].ti_Data = 300;
	tagitem[4].ti_Tag = WA_Borderless;
	tagitem[4].ti_Data = 1;
	tagitem[5].ti_Tag = WA_NoCareRefresh;
	tagitem[5].ti_Data = 1;
	tagitem[6].ti_Tag = WA_IDCMP;
	tagitem[6].ti_Data = 0;
	tagitem[7].ti_Tag = TAG_DONE;

        if (!(window = OpenWindowTagList(NULL, tagitem))) {
		UnlockPubScreen(NULL, screen);
		UnlockIBase(ilock);
		return 1;
	}

	UnlockPubScreen(NULL, screen);
	UnlockIBase(ilock);

	Delay(200);
        CloseWindow(window);
	
	return 0;
}
I also tried the above code with OpenLibrary/CloseLibrary with Intuition.library. NULLing the window->RastPort, reply to UserPort msgs (even though it should not be needed with no IDCMP flags and NOCAREREFRESH + Borderless.

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!!)

Last edited by edmayn; 19 February 2021 at 00:04.
edmayn is offline  
Old 19 February 2021, 11:02   #13
edmayn
Registered User

 
Join Date: May 2017
Location: Silkeborg/Denmark
Posts: 21
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.
edmayn is offline  
Old 19 February 2021, 11:41   #14
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 991
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 is online now  
Old 19 February 2021, 12:14   #15
edmayn
Registered User

 
Join Date: May 2017
Location: Silkeborg/Denmark
Posts: 21
@Thomas Richter
Ah, devil is in the details (as always).

Indeed specifying the exact path solves the problem.

Thanks.

(Lol that was a timesink)
edmayn is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Ray tracing software for A500? Jake001 request.Apps 10 23 August 2020 19:57
Tracing an old forum user Total Eclipse Retrogaming General Discussion 3 15 March 2016 00:08
Want to start ray-tracing watertonian support.Apps 48 27 January 2014 10:38
Clipboard memory leak Leandro Jardim support.WinUAE 2 21 February 2012 22:48
Memory Leak on A1200 with CWB FULL DDNI project.ClassicWB 2 18 August 2006 20:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.08005 seconds with 15 queries