You are, most likely, manually allocating/deallocating memory

you store pointers to polymorphic classes

Upp::Vector<DiscordModule*> AllModules;

which do not have a virtual destructor, in a container

class SmartBotUpp{
	private: 
		Upp::Vector<DiscordModule*> AllModules;
		Discord bot;
		
		Upp::String name="";
		Upp::String token="";
		
		void Event(ValueMap payload);
		Discord* getBotPtr();
	public:
...
};

SmartBotUpp::~SmartBotUpp(){
AllModules.Clear();
}

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.

AllModules.Clear();

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.

MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		UPP::MemoryDumpLeaks();
}

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

Hello Novo, Thanks for the precision about valgrind.
Sadly I dont have linux atm. have you a windows alternative ?

Hello Novo, Thanks for the precision about valgrind.
Sadly I dont have linux atm. have you a windows alternative ?

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.

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

Mirek

Move to Linux Rolling Eyes

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

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.

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.

"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 ...

#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");
}

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>

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 is not a correct behavior.

Novo wrote on Mon, 15 July 2019 06:15

This is not a correct behavior.

There is no correct behaviour. This is not defined anywhere in c++ standard.

Mirek

mirek wrote on Mon, 15 July 2019 02:17

Novo wrote on Mon, 15 July 2019 06:15

This is not a correct behavior.

There is no correct behaviour. This is not defined anywhere in c++ standard.

Mirek

In this case this is a bug with U++. MemDiagCls shouldn't be a global object. It should be created on stack (by GUI_APP_MAIN or by CONSOLE_APP_MAIN). IMHO.

Novo wrote on Mon, 15 July 2019 17:16

mirek wrote on Mon, 15 July 2019 02:17

Novo wrote on Mon, 15 July 2019 06:15

This is not a correct behavior.

There is no correct behaviour. This is not defined anywhere in c++ standard.

Mirek

In this case this is a bug with U++. MemDiagCls shouldn't be a global object. It should be created on stack (by GUI_APP_MAIN or by CONSOLE_APP_MAIN). IMHO.

Then it would not work. Think about all that memory allocated in global objects... (and worse, not in initialization phase).

mirek wrote on Mon, 15 July 2019 13:35

Novo wrote on Mon, 15 July 2019 17:16

mirek wrote on Mon, 15 July 2019 02:17

Novo wrote on Mon, 15 July 2019 06:15

This is not a correct behavior.

There is no correct behaviour. This is not defined anywhere in c++ standard.

Mirek

In this case this is a bug with U++. MemDiagCls shouldn't be a global object. It should be created on stack (by GUI_APP_MAIN or by CONSOLE_APP_MAIN). IMHO.

Then it would not work. Think about all that memory allocated in global objects... (and worse, not in initialization phase).

Instead of MemDiagCls you can put on stack a guard-object, which will detect that its destructor got called and set a flag on MemDiagCls.
IMHO, the problem is fixable ...

Yeah, but then I will not catch leaks in global objects.

mirek wrote on Mon, 15 July 2019 18:11

Yeah, but then I will not catch leaks in global objects.

I do not understand why. Just do not show memory leak report when an object on stack wasn't destroyed.

struct Foo {
   byte *ptr;

   ~Foo() { if(ptr) delete[] ptr; } // this might be missing
};

Foo foo;

CONSOLE_APP_MAIN {
   foo.ptr = new byte[1000];
}

Maybe we are nor speaking about the same thing...

struct MemDiagCls {
	MemDiagCls();
	~MemDiagCls();
	
	static void ShowReport() { show = true; }
	static bool IsShowReport() { return show; }
	
private:
	static bool show;
};
bool MemDiagCls::show = false;

MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		if (IsShowReport())
			UPP::MemoryDumpLeaks();
}

struct LeakRepGuard {
	~LeakRepGuard();
};

LeakRepGuard::~LeakRepGuard() {
	MemDiagCls::ShowReport();
}

#define CONSOLE_APP_MAIN \
void ConsoleMainFn_(); \
 \
int main(int argc, char *argv[]) { \
	UPP::LeakRepGuard __; \
	UPP::AppInit__(argc, (const char **)argv); \
	UPP::AppExecute__(ConsoleMainFn_); \
	UPP::AppExit__(); \
	return UPP::GetExitCode(); \
} \
 \
void ConsoleMainFn_()

mirek wrote on Tue, 16 July 2019 03:38

Maybe we are nor speaking about the same thing...

What I mean is

struct MemDiagCls {
	MemDiagCls();
	~MemDiagCls();
	
	static void ShowReport() { show = true; }
	static bool IsShowReport() { return show; }
	
private:
	static bool show;
};
bool MemDiagCls::show = false;

MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		if (IsShowReport())
			UPP::MemoryDumpLeaks();
}

struct LeakRepGuard {
	~LeakRepGuard();
};

LeakRepGuard::~LeakRepGuard() {
	MemDiagCls::ShowReport();
}

#define CONSOLE_APP_MAIN \
void ConsoleMainFn_(); \
 \
int main(int argc, char *argv[]) { \
	UPP::LeakRepGuard __; \
	UPP::AppInit__(argc, (const char **)argv); \
	UPP::AppExecute__(ConsoleMainFn_); \
	UPP::AppExit__(); \
	return UPP::GetExitCode(); \
} \
 \
void ConsoleMainFn_()

A call to UPP::MemoryDumpLeaks() will be disabled if there was no stack unwinding. In all other cases it will work as before.
Leak report makes no sense when destructors of objects on stack were not called.
IMHO, this should be thread-safe because there is only one main() function ...

Leak report makes no sense when destructors of objects on stack were not called.

Novo wrote on Wed, 17 July 2019 18:44

Leak report makes no sense when destructors of objects on stack were not called.

This is debatable. It would warn you about calling "exit(0)" or equivalent, which is IMO good.

MemDiagCls::~MemDiagCls()
{
	if(--sMemDiagInitCount == 0)
		if (IsShowReport())
			UPP::MemoryDumpLeaks();
		else
			UPP::Cerr() << "The World is going to end soon!" << UPP::EOL;
}