Regarding the memory leak:
This is something that I've sent to BlueG in February 2012
Quote:
|
Originally Posted by BlueG
Quote:
|
Originally Posted by xxmitsu
Hello,
It's been awhile since I wrote you I must say that I'm using your R7 plugin since about 2 month and a half and it's running flawless. Thank you!
But... somehow, yesterday one strange thing happened. The server was offline:
Quote:
Out of memory (Needed 16384 bytes)
Out of memory (Needed 16384 bytes)
Out of memory (Needed 16384 bytes)
Segmentation fault
|
So I thought what could have happened with 1.5 gig of RAM ?
then..
I've found an interesting article about debugging memory leaks:
http://www.linuxprogrammingblog.com/...g-memory-leaks
I've tested it and I've seen some strange stuffs detected:
Quote:
At the beginning of using Valgrind to debug my programs I used to think this way: It's just an automatic, dumb tool that tracks memory allocations and can be wrong. I looked at the code and there can be no memory leak at this point, it's one of the cases when Valgrind is wrong.. But I was wrong! After years of using it I can see that 99,9% of it's messages are right but it's often hard to see it in the code.
One real world case was when I was writing a multi-threaded program that used libmysqlclient library and valgrind showed memory leaks in mysql_real_connect()/mysql_init(). It's clear from documentation that the memory allocated by the library when using those functions should be freed by mysql_close(). From the code it was clear that I do it properly: every created connection was closed. I even added a counter to the places when I create connection and destroy it and saw all connections were destroyed. I started to think that there is a memory leak in the libmysqlclient_r library (a thread-safe version) but when I separated the code (wrote a simple program that allocates conenctions and free them) Valgrind showed no errors. So there are no leaks in the library. If I had less believe in Valgrind I would give up at this moment, but I knew it's right. As I found out there is a special requirement by libmysqlclient_r, I just didn't read the documentation. If you are creating MYSQL objects in different threads the library automatically allocates per-thread global data, but to free them you must use mysql_thread_end(). It's not done automatically in contrast to allocation.
|
So, would it be needed to use mysql_thread_end(); in your source code, perhaps in the area of
Код:
}
}
Mutex::getInstance()->_unlockMutex();
//we use sleep to avoid memory leaks etc.
SLEEP(5);
}
}
In your main.cpp ?
PS: Perhaps I'm wrong and I'm just disturbing you. Well then, once again, sorry for disturbing.
Thanks in advance,
Mike. |
Hey,
thanks for that information. I've released the source code, because of a lack of time. It's not the final release and I might make some important changes if I get the time.
I will try to find out more about that problem you got.
Anyway,
peace out o/ |
Idk if he had the time since then to check out and test the information.
Cheers,
