Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Newbie corner » CTRL + C = 659 Heap leaks
CTRL + C = 659 Heap leaks [message #52037] Wed, 10 July 2019 21:05 Go to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
Hello,

When I press Ctrl + C on my programme, I got this kind of thing in the Log :
Heap leaks detected:

--memory-breakpoint__ 33474 : Memory at 0x09110dd0, size 0xC = 12
    +0 0x09110DD0 10 13 1A 09 00 72 65 65 46 72 65 65                 .....reeFree    

--memory-breakpoint__ 33473 : Memory at 0x091a1310, size 0x2C = 44
    +0 0x091A1310 7C 12 BA 00 01 00 00 00 38 EF CC 03 B4 2E 40 00     |.......8.....@.
   +16 0x091A1320 00 00 00 00 22 A1 00 00 EC EF CC 03 46 72 65 65     ....".......Free
   +32 0x091A1330 46 72 65 65 46 72 65 65 46 72 65 65                 FreeFreeFree    

--memory-breakpoint__ 33472 : Memory at 0x09198f10, size 0x2C = 44
    +0 0x09198F10 74 9D B9 00 01 00 00 00 00 00 00 00 00 00 00 00     t...............
   +16 0x09198F20 00 00 00 00 00 00 00 00 00 00 00 00 18 8F 19 09     ................
   +32 0x09198F30 46 72 65 65 46 72 65 65 46 72 65 65                 FreeFreeFree    

...

*** TOO MANY LEAKS (659) TO LIST THEM ALL

Is it preventable ? or it happen only because I shutdowned the code by using Ctrl + C ?

PS : by doing some coding stuff to stop my programm by code, nothing happen

Best Regard

[Updated on: Wed, 10 July 2019 22:43]

Report message to a moderator

Re: CTRL + C = 659 Heap leaks [message #52038 is a reply to message #52037] Thu, 11 July 2019 06:06 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
Most likely your code has an error (or errors) in its logic. You are, most likely, manually allocating/deallocating memory, or you store pointers to polymorphic classes, which do not have a virtual destructor, in a container. Something like that.
AFAIK, you can click on memory leaks in TheIDE, and it will show you where this memory was allocated. I can be wrong, I haven't seen memory leaks in my code for very very long time Rolling Eyes

One interesting thing about U++ is that you almost never need to call new/delete or malloc/free.
It is like programming in Java/JavaScript/Lua/Python/Ruby ...


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52039 is a reply to message #52037] Thu, 11 July 2019 09:36 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
Hello Novo, Thanks for you reply.

Quote:
You are, most likely, manually allocating/deallocating memory

Don't think so, I never use New or malloc.

Quote:
you store pointers to polymorphic classes

In my code I use lot of Ptr of type "DiscordModule", the mother class of lot of object stored in this kind of thing :
Upp::Vector<DiscordModule*> AllModules;

I thought it come from that but by launching my code without filling that vector still result on the same huge amount of memory leak !

Quote:
which do not have a virtual destructor, in a container

I tried to declare destructor -> here is definition of my class :
class SmartBotUpp{
	private: 
		Upp::Vector<DiscordModule*> AllModules;
		Discord bot;
		
		Upp::String name="";
		Upp::String token="";
		
		void Event(ValueMap payload);
		Discord* getBotPtr();
	public:
...
};

and here is the destructor
SmartBotUpp::~SmartBotUpp(){
AllModules.Clear();
}


Quote:
AFAIK, you can click on memory leaks in TheIDE, and it will show you where this memory was allocated. I can be wrong, I haven't seen memory leaks in my code for very very long time Rolling Eyes


How you do it ? I get all the memory leak by looking log on theIDE but it's not clickable

Quote:
One interesting thing about U++ is that you almost never need to call new/delete or malloc/free.
Yeah that's exactly what I'm doing. That's why I'm lost Very Happy

Best regard.
Re: CTRL + C = 659 Heap leaks [message #52040 is a reply to message #52039] Thu, 11 July 2019 09:57 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 574
Registered: August 2007
Location: Turkey
Contributor
Hello Xemuth,
Quote:

AllModules.Clear();


As far as I can see, with this code you are simply deleting the pointers to allocated objects. This code doesn't delete the objects pointed, If those objects are allocated with the "new" keyword and not deleded elswhere, then the heap leaks you are getting are the natural result. Smile

Best regards,
Oblivion





[Updated on: Thu, 11 July 2019 09:58]

Report message to a moderator

Re: CTRL + C = 659 Heap leaks [message #52041 is a reply to message #52037] Thu, 11 July 2019 10:10 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
yeah but the object pointed by this ptr from AllModules are allocated in stack from the main :

CONSOLE_APP_MAIN {
	StdLogSetup(LOG_COUT|LOG_FILE);

	SmartBotUpp mybot(myBotID,myBotToken);
	
	Discord_Overwatch ow("OverWatch","ow");
	mybot.AddModule(&ow);

	Discord_Minecraft mc("Minecraft","mc");
	mybot.AddModule(&mc);

	mybot.Launch();
}


So, if I understand well, it should be destroyed at end of the main. I'm right ? Embarassed
Maybe I should rewrite the code and try to store references instead of Ptr's.

[Updated on: Thu, 11 July 2019 10:13]

Report message to a moderator

Re: CTRL + C = 659 Heap leaks [message #52042 is a reply to message #52041] Thu, 11 July 2019 10:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11991
Registered: November 2005
Ultimate Member
Well, your method(s) seems fine (although I would probably use static module variables instead of locals in CONSOLE_APP_MAIN).

So, this is console application in POSIX and you are pressing Ctrl+C to terminate it. AFAIK, Ctrl+C just calls exit, which is what is causing the leaks, as 'mybot' never gets destroyed.

Hard to say if there is anything to fix. This behaviour will only exist in Debug mode, in release all will be fine. If this is too annoying, we might consider installing handler that switches leaks testing off...
Re: CTRL + C = 659 Heap leaks [message #52043 is a reply to message #52037] Thu, 11 July 2019 10:28 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
In my code I'm using this lib :

https://github.com/BornTactical/DiscordUpp

in this, Atomic is used and even lib simple example, result in lot of memory leaks.
Maybe it's because of "Atomic" ?
Re: CTRL + C = 659 Heap leaks [message #52044 is a reply to message #52037] Thu, 11 July 2019 10:30 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
Hello Mirek, It's clear, Thank you. I though my code was allocating data without desalocating it while running
Re: CTRL + C = 659 Heap leaks [message #52046 is a reply to message #52042] Thu, 11 July 2019 16:42 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
mirek wrote on Thu, 11 July 2019 04:22

So, this is console application in POSIX and you are pressing Ctrl+C to terminate it. AFAIK, Ctrl+C just calls exit, which is what is causing the leaks, as 'mybot' never gets destroyed.

Ctrl+C sends SIGINT, which causes "soft" termination of an app (unlike SIGKILL). It does all cleanup job for the process including stack unwinding (at least in x64 Linux).

Proof:
Memory leak report is a result of a call to UPP::MemoryDumpLeaks(), and it is called by
MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		UPP::MemoryDumpLeaks();
}


So, stack gets unwinded, but in case of Xemuth memory doesn't get deallocated.
This is a bug with Xemuth's code. Embarassed


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52047 is a reply to message #52039] Thu, 11 July 2019 17:10 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
Xemuth wrote on Thu, 11 July 2019 03:36

Quote:
AFAIK, you can click on memory leaks in TheIDE, and it will show you where this memory was allocated. I can be wrong, I haven't seen memory leaks in my code for very very long time Rolling Eyes


How you do it ? I get all the memory leak by looking log on theIDE but it's not clickable

I, probably, saw that somewhere else ...

Another approach:
1) compile your code with a .USEMALLOC flag. That will switch to glibc's allocator
2) run valgrind your_app
3) press CTRL-C

you will get detailed information about memory leaks.

There is also Debug --> "Test in Valgring" in TheIde, but I personally always use valgrind from command line ...


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52051 is a reply to message #52037] Thu, 11 July 2019 22:13 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
Hello Novo, Thanks for the precision about valgrind.
Sadly I dont have linux atm. have you a windows alternative Very Happy ?
Re: CTRL + C = 659 Heap leaks [message #52052 is a reply to message #52051] Thu, 11 July 2019 22:24 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
Xemuth wrote on Thu, 11 July 2019 16:13
Hello Novo, Thanks for the precision about valgrind.
Sadly I dont have linux atm. have you a windows alternative Very Happy ?

Intel Inspector, but it is not free Sad
Move to Linux Rolling Eyes


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52053 is a reply to message #52051] Thu, 11 July 2019 22:31 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
Xemuth wrote on Thu, 11 July 2019 16:13
Hello Novo, Thanks for the precision about valgrind.
Sadly I dont have linux atm. have you a windows alternative Very Happy ?

Yet another tool:
https://clang.llvm.org/docs/AddressSanitizer.html
https://en.wikipedia.org/wiki/AddressSanitizer

Theoretically, it should work with mingw. It definitely works on Linux Rolling Eyes


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52054 is a reply to message #52046] Fri, 12 July 2019 00:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11991
Registered: November 2005
Ultimate Member
Novo wrote on Thu, 11 July 2019 16:42
mirek wrote on Thu, 11 July 2019 04:22

So, this is console application in POSIX and you are pressing Ctrl+C to terminate it. AFAIK, Ctrl+C just calls exit, which is what is causing the leaks, as 'mybot' never gets destroyed.

Ctrl+C sends SIGINT, which causes "soft" termination of an app (unlike SIGKILL). It does all cleanup job for the process including stack unwinding (at least in x64 Linux).

Proof:
Memory leak report is a result of a call to UPP::MemoryDumpLeaks(), and it is called by
MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		UPP::MemoryDumpLeaks();
}


So, stack gets unwinded, but in case of Xemuth memory doesn't get deallocated.
This is a bug with Xemuth's code. Embarassed


I believe you are wrong. I believe Ctrl+C is equivalent of calling exit(). In that case, global variables get destructed, but local variables do not. This is also quite clear for the implementation of signals - they are asynchronouse and thus do not have to use the same stack so no stack unwinding is possible.

BTW, destructing global variables is the mechanism used to activate the leak checker Smile

Mirek
Re: CTRL + C = 659 Heap leaks [message #52055 is a reply to message #52054] Fri, 12 July 2019 00:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11991
Registered: November 2005
Ultimate Member
BTW, about hunting down leaks (even if I believe there are not any here):

In the log you can see:

--memory-breakpoint__ 33474

If the allocation pattern is stable (like the number is always the same in any run), you can resolve the leak by putting this to commandline when running the code - this will cause an exception when the same allocation is done again.
Re: CTRL + C = 659 Heap leaks [message #52056 is a reply to message #52054] Fri, 12 July 2019 00:46 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
mirek wrote on Thu, 11 July 2019 18:15

I believe you are wrong. I believe Ctrl+C is equivalent of calling exit(). In that case, global variables get destructed, but local variables do not. This is also quite clear for the implementation of signals - they are asynchronouse and thus do not have to use the same stack so no stack unwinding is possible.

BTW, destructing global variables is the mechanism used to activate the leak checker Smile

Mirek

I saw that MemDiagCls is a global static ...
Let's say only global statics get destroyed, and stack doesn't get unwinded. In such case every time you press CTRL-C you should get memory leaks. But this never happens to my apps ... BTW, info for stack unwinding is always included into app, especially when you compile it with exception support (this is related to x64 Win and POSIX ABI).

"no stack unwinding is possible" - try to run an app with gdb and press CTRL-C. gdb will stop each thread in your app and will show you call stacks for each thread. Call stack for each thread can we unwinded, IMHO ...

This is my understanding of this process ...


Regards,
Novo
Re: CTRL + C = 659 Heap leaks [message #52057 is a reply to message #52037] Fri, 12 July 2019 09:28 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 98
Registered: August 2018
Location: France
Member
Quote:
Move to Linux Rolling Eyes
Yeah it's plannified Very Happy

Quote:
https://clang.llvm.org/docs/AddressSanitizer.html
https://en.wikipedia.org/wiki/AddressSanitizer

Will try it, if Mirek proposition don't help me in reliable way
Quote:
In the log you can see:

--memory-breakpoint__ 33474

If the allocation pattern is stable (like the number is always the same in any run), you can resolve the leak by putting this to commandline when running the code - this will cause an exception when the same allocation is done again.


By looking from Internet, SIGINT signal send by "Ctrl + C" on windows 10
Quote:
SIGINT: This signal interrupts a process immediately.The default action of this signal is to terminate a process gracefully .It can be handled , ignored or caught .It can be sent from a terminal as input characters .this signal is generated when a user presses Ctrl+C.


Seems like you must handle it. So I guess Upp or Std have handler somewhere in the code ? Also it mean the process probably the same on Windows and Linux ?
Furthermore, By looking on SigInt I find a funny picture and I'd share it Very Happy
https://qph.fs.quoracdn.net/main-qimg-1180ef2465c309928b02481f02580c6a
Re: CTRL + C = 659 Heap leaks [message #52058 is a reply to message #52056] Fri, 12 July 2019 09:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11991
Registered: November 2005
Ultimate Member
[quote title=Novo wrote on Fri, 12 July 2019 00:46]mirek wrote on Thu, 11 July 2019 18:15


"no stack unwinding is possible" - try to run an app with gdb and press CTRL-C. gdb will stop each thread in your app and will show you call stacks for each thread. Call stack for each thread can we unwinded, IMHO ...


Ctrl+C here goes to gdb, which catches and handles it.... So unrelated.

#include <Core/Core.h>

using namespace Upp;

EXITBLOCK {
	RLOG("Exit");
}

CONSOLE_APP_MAIN
{
	StdLogSetup(LOG_COUT|LOG_FILE);
	Buffer<byte> x(1000);
	RLOG("Here");
	for(;;) Sleep(1);
	RLOG("After ctrl+c");
}


In win32, if you run this in console and press Ctrl+C:

PS C:\xxx> ./Console
Here
Exit


Heap leaks detected:

--memory-breakpoint__ 736 : Memory at 0x0000000006b1d570, size 0x4CC = 1228
    +0 0x0000000006B1D570 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +16 0x0000000006B1D580 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +32 0x0000000006B1D590 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +48 0x0000000006B1D5A0 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
PS C:\xxx>

Re: CTRL + C = 659 Heap leaks [message #52059 is a reply to message #52058] Fri, 12 July 2019 09:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11991
Registered: November 2005
Ultimate Member
Interestingly, in Linux, process is terminated without any cleanup:

cxl@Linux:~$ ./CtrlC
Here
^C
cxl@Linux:~$ 


so no leaks reported...
Re: CTRL + C = 659 Heap leaks [message #52067 is a reply to message #52058] Mon, 15 July 2019 06:15 Go to previous messageGo to previous message
Novo is currently offline  Novo
Messages: 878
Registered: December 2006
Experienced Contributor
mirek wrote on Fri, 12 July 2019 03:44

In win32, if you run this in console and press Ctrl+C:

PS C:\xxx> ./Console
Here
Exit


Heap leaks detected:

--memory-breakpoint__ 736 : Memory at 0x0000000006b1d570, size 0x4CC = 1228
    +0 0x0000000006B1D570 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +16 0x0000000006B1D580 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +32 0x0000000006B1D590 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
   +48 0x0000000006B1D5A0 46 72 65 65 46 72 65 65 46 72 65 65 46 72 65 65     FreeFreeFreeFree
PS C:\xxx>


This explains everything.
On Windows stack doesn't get unwinded, but descructors of global objects are still called. This is not a correct behavior.
In the old 32-bit Win ABI CRT was responsible for calling descructors of global objects. I do not know how this is implemented in the x64 ABI, most likely the same way.

When I strace my app in Linux I do see an exit_group(0) call on normal run (no CTRL-C).
I do not see any system calls when I press CTRL-C ...
This is an interesting topic ...
I guess, SIGINT is handled completely by glibc in Linux ...
Sending SIGINT directly to a process from another shell doesn't change anything ...


Regards,
Novo
Previous Topic: How i can play a sound?? wav,mp3,ogg,aiff????
Next Topic: Filtering an ArrayCtrl
Goto Forum:
  


Current Time: Thu Aug 22 05:30:29 CEST 2019

Total time taken to generate the page: 0.01036 seconds