List:MySQL++« Previous MessageNext Message »
From:Tamás Kása Date:July 21 2014 2:11pm
Subject:Possible memory leak on 64bit CentOS
View as plain text  
I connect to the database and valgrind shows a memory leak originating
from the MySQL++ connection variable. The database and user exists,
the connection is successful.
My test code:

// test.cpp ----------------------------------------------
#include <mysql++.h>

int main(int argc, char **argv) {
mysqlpp::Connection connMain(true);
try {
connMain.connect("mysql", "localhost", "test", "test");
        if(connMain.connected()) printf("MySQL connection opened.\n");
} catch (const mysqlpp::BadQuery& er) {
printf("MySQL query error: %s\n", er.what());
} catch (const mysqlpp::Exception& er) {
printf("MySQL error: %s\n", er.what());


return 0;
// -------------------------------------------------------------

I'm compiling the code with this makefile:
CXX := /usr/bin/g++
CXXFLAGS :=  -I/usr/include/mysql -I/usr/local/include/mysql++ -g -Wall
LDFLAGS := -L/usr/lib64 -L/usr/local/lib64 -L/usr/lib/mysql
-Wl,-rpath /usr/local/lib
LDLIBS := -lmysqlpp -lmysqlclient

all: $(EXECUTABLE) cleanobjects

rm -f *.o

test.o: test.cpp
${CXX} ${CXXFLAGS} -c test.cpp

test: test.o

rm -f $(EXECUTABLE) *.o

I'm using the following valgrind command to examine memory usage:
valgrind --leak-check=yes --track-origins=yes --log-file=test.log ./test

The test.log contents:
==11123== Memcheck, a memory error detector
==11123== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==11123== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==11123== Command: ./test
==11123== Parent PID: 9090
==11123== HEAP SUMMARY:
==11123==     in use at exit: 576 bytes in 2 blocks
==11123==   total heap usage: 109 allocs, 107 frees, 97,590 bytes allocated
==11123== 576 (64 direct, 512 indirect) bytes in 1 blocks are
definitely lost in loss record 2 of 2
==11123==    at 0x4A0695E: operator new(unsigned long) (vg_replace_malloc.c:220)
==11123==    by 0x4C2CED3: std::_Deque_base<mysqlpp::Option*,
std::allocator<mysqlpp::Option*> >::_M_initialize_map(unsigned long)
==11123==    by 0x4C2CAD5: mysqlpp::DBDriver::DBDriver() (stl_deque.h:368)
==11123==    by 0x4C27294: mysqlpp::Connection::Connection(bool)
==11123==    by 0x400E21: main (test.cpp:4)
==11123== LEAK SUMMARY:
==11123==    definitely lost: 64 bytes in 1 blocks
==11123==    indirectly lost: 512 bytes in 1 blocks
==11123==      possibly lost: 0 bytes in 0 blocks
==11123==    still reachable: 0 bytes in 0 blocks
==11123==         suppressed: 0 bytes in 0 blocks
==11123== For counts of detected and suppressed errors, rerun with: -v
==11123== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

uname -a output:
Linux *** 2.6.18-308.8.2.el5 #1 SMP Tue Jun 12 09:58:12 EDT 2012
x86_64 x86_64 x86_64 GNU/Linux

My g++ version:
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)

My MySQL server version: 5.0.95

I'm using the 3.2.1 version of MySQL++, I've installed it without
parameters from source:
make install

The described leak occurs every time when a mysqlpp object is created
(for example Query objects). Because I'm writing a server program with
infinite loop which periodically (every second) checks the database
for changes and processes the new data with multiple subqueries, the
leaked bytes accumulate fast, rendering the server program useless.

What am I doing wrong, or how can I free the resources? I believe I'm
following the instructions in the documentation regarding memory

The curious thing is that the test.cpp doesn't leak memory when
compiled on a virtual system, which is exactly the same as the other
mentioned above, except it is a 32 bit CentOS system, not 64 bit.

Thank you for your help.
Possible memory leak on 64bit CentOSTamás Kása21 Jul
  • Re: Possible memory leak on 64bit CentOSWarren Young21 Jul
  • Re: Possible memory leak on 64bit CentOSChris Frey21 Jul
    • Re: Possible memory leak on 64bit CentOSTamás Kása22 Jul
      • Re: Possible memory leak on 64bit CentOSTamás Kása28 Jul
        • Re: Possible memory leak on 64bit CentOSWarren Young28 Jul