You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Date: 2012-08-21 15:37:35 +0200
From: info
To: MonetDB5 devs <>
Version: -- development
CC: arkr17997, hotekabop, @yzchang
Last updated: 2019-10-31 13:35:49 +0100
Comment 17634
Date: 2012-08-21 15:37:35 +0200
From: info
Created attachment 140
Valgrind logging
monetdb --version
MonetDB Database Server Toolkit v1.0 (Jul2012-SP1)
There seems to be a memory leak when making a connection. The amount of bytes leaked increase with each connection. We have tested this with both mclient and mapi(C-code). Mclient shows an additional leak compared to connecting with mapi. The first connection made to a database also seems to have some extra leakage.
I've added an archive with valgrind logging.
MAPI:
For mapi we used the following C-program:
Mapi dbh = NULL;
dbh = mapi_connect("localhost", 50000, "monetdb", "monetdb", "sql", "connectionmapi");
mapi_destroy(dbh);
Date: 2012-08-21 15:37:35 +0200
From: info
To: MonetDB5 devs <>
Version: -- development
CC: arkr17997, hotekabop, @yzchang
Last updated: 2019-10-31 13:35:49 +0100
Comment 17634
Date: 2012-08-21 15:37:35 +0200
From: info
Created attachment 140
Valgrind logging
monetdb --version
MonetDB Database Server Toolkit v1.0 (Jul2012-SP1)
There seems to be a memory leak when making a connection. The amount of bytes leaked increase with each connection. We have tested this with both mclient and mapi(C-code). Mclient shows an additional leak compared to connecting with mapi. The first connection made to a database also seems to have some extra leakage.
I've added an archive with valgrind logging.
MAPI:
For mapi we used the following C-program:
Mapi dbh = NULL;
dbh = mapi_connect("localhost", 50000, "monetdb", "monetdb", "sql", "connectionmapi");
mapi_destroy(dbh);
Test: No connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmapi >& output_mserver5_mapi.txt
Terminal1: \q
==26903== definitely lost: 216 bytes in 3 blocks
Test: 1st connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmapi >& output_mserver5_mapi_1st.txt
Terminal2: ./Program
Terminal1: \q
==26955== definitely lost: 237,648 bytes in 116 blocks
Test: 2nd connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmapi >& output_mserver5_mapi_2nd.txt
Terminal2: ./Program
Terminal1: \q
==27001== definitely lost: 40 bytes in 1 blocks
Test: 3rd connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmapi >& output_mserver5_mapi_3rd.txt
Terminal2: ./Program
Terminal1: \q
==27034== definitely lost: 40 bytes in 1 blocks
Test: 4th + 5th connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmapi >& output_mserver5_mapi_4th_5th.txt
Terminal2: ./Program
Terminal2: ./Program
Terminal1: \q
==27071== definitely lost: 80 bytes in 2 blocks
MCLIENT:
Test: No connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmclient >& output_mserver5_mclient.txt
Terminal1: \q
==26105== definitely lost: 216 bytes in 3 blocks
Test: 1st connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmclient >& output_mserver5_mclient_1st.txt
Terminal2: mclient -dconnectionmclient
Terminal2: \q
Terminal1: \q
==26147== definitely lost: 238,824 bytes in 117 blocks
Test: 2nd connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmclient >& output_mserver5_mclient_2nd.txt
Terminal2: mclient -dconnectionmclient
Terminal2: \q
Terminal1: \q
==26229== definitely lost: 1,216 bytes in 2 blocks
Test: 3rd connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmclient >& output_mserver5_mclient_3rd.txt
Terminal2: mclient -dconnectionmclient
Terminal2: \q
Terminal1: \q
==26293== definitely lost: 1,216 bytes in 2 blocks
Test: 4th + 5th connection
Terminal1: valgrind --leak-check=full mserver5 --set gdk_alloc_map=no --dbname=connectionmclient >& output_mserver5_mclient_4th_5th.txt
Terminal2: mclient -dconnectionmclient
Terminal2: \q
Terminal2: mclient -dconnectionmclient
Terminal2: \q
Terminal1: \q
==26415== definitely lost: 2,432 bytes in 4 blocks
Comment 17650
Date: 2012-08-24 12:33:32 +0200
From: @sjoerdmullender
Changeset 1a1256bc8d44 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=1a1256bc8d44
Changeset description:
Comment 17651
Date: 2012-08-24 13:56:19 +0200
From: @sjoerdmullender
Changeset 1db88d19e874 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=1db88d19e874
Changeset description:
Comment 17652
Date: 2012-08-24 14:37:11 +0200
From: @sjoerdmullender
Changeset 293d29d8bec2 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=293d29d8bec2
Changeset description:
Comment 17653
Date: 2012-08-24 14:48:08 +0200
From: @sjoerdmullender
With the three sets of fixes I now get 0 definitely lost bytes of memory when I replay the mclient tests.
This'll be in Jul2012-SP2.
Comment 18049
Date: 2012-11-27 13:19:34 +0100
From: @yzchang
Don't know how to add test for this bug
The text was updated successfully, but these errors were encountered: