Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memleak when connecting to a database (mclient and mapi) #3144

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

Memleak when connecting to a database (mclient and mapi) #3144

monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working major MAL/M5

Comments

@monetdb-team
Copy link

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

Attached file: connection_leak.tar.bz2 (application/x-bzip, 254089 bytes)
Description: Valgrind logging

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:

Fix memory leak.
The lifespan info wasn't used in the groups optimizer, and what's
worse, it wasn't freed.
This fixes (part of) bug #3144.

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:

Plug memory leak.
Part of fixing bug #3144.

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:

Plug some more memory leaks.
Fixes for bug #3144.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working major MAL/M5
Projects
None yet
Development

No branches or pull requests

2 participants