Bugs item #1498247, was opened at 2006-05-31 07:12
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1498247&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Mapi
Group: MonetDB4 CVS Head
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marcin Zukowski (e-r00)
Assigned to: Sjoerd Mullender (sjoerd)
Summary: Mapi leak
Initial Comment:
Mapi seems to leak memory used to store header
information (column/type names).
I modified smack00.c to print a bat instead of a number:
snprintf(buf, 40, "print(new(int,int));");
so the header is added, and here's the trace after
10000 runs:
120,000 bytes in 40,000 blocks are definitely lost in
loss record 4 of
at 0x4904A66: malloc (vg_replace_malloc.c:149)
by 0x4A152A3: unquote (Mapi.mx:3850)
by 0x4A11A29: slice_row (Mapi.mx:2813)
by 0x4A1245E: parse_header_line (Mapi.mx:3008)
by 0x4A12B61: read_into_cache (Mapi.mx:3135)
by 0x4A135B5: mapi_execute_internal (Mapi.mx:3289)
by 0x4A13811: mapi_query (Mapi.mx:3326)
by 0x400C8F: main (smack00.c:67)
It is a bit important wrt our coming Terabyte TREC
experiments, as we run tens of thousands of queries.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2007-11-29 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 365 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2006-11-29 02:07
Message:
Logged In: YES
user_id=572415
Originator: NO
Marked as pending to jon the club of missing memory related tests.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-06-19 07:00
Message:
Logged In: YES
user_id=43607
Closing since I think the bugs are fixed.
Not adding a test since we don't have any tests that test
for memory leaks.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-06-08 06:03
Message:
Logged In: YES
user_id=43607
I fixed a leak in smack01: it disconnected and then
discarded the Mapi structure, but discarding is not freeing.
We now reuse the Mapi structure in the loop, merely
reconnecting and disconnecting in each iteration.
----------------------------------------------------------------------
Comment By: Marcin Zukowski (e-r00)
Date: 2006-06-08 05:46
Message:
Logged In: YES
user_id=607094
In smack01 (modified with "print(new(int,int))") there are
still leaks related to the number of connections.
2K runs, see attached smack01-client
59,970 bytes in 7,996 blocks are indirectly lost in loss
record 6 of 9
at 0x4904A66: malloc (vg_replace_malloc.c:149)
by 0x334C8724B1: strdup (in /lib64/libc-2.3.6.so)
by 0x4A0DFEF: mapi_mapi (Mapi.mx:1754)
by 0x4A0F83E: mapi_connect (Mapi.mx:2189)
by 0x400C85: main (smack01.c:58)
32,992,047 (415,792 direct, 32,576,255 indirect) bytes in
1,999 blocks
are definitely lost in loss record 8 of 9
at 0x4904A66: malloc (vg_replace_malloc.c:149)
by 0x4A0DDBC: mapi_new (Mapi.mx:1697)
by 0x4A0DFBA: mapi_mapi (Mapi.mx:1748)
by 0x4A0F83E: mapi_connect (Mapi.mx:2189)
by 0x400C85: main (smack01.c:58)
32,516,285 bytes in 1,985 blocks are indirectly lost in loss
record 9
of 9
at 0x4905EC2: realloc (vg_replace_malloc.c:306)
by 0x4A11D49: read_line (Mapi.mx:2716)
by 0x4A1347A: read_into_cache (Mapi.mx:3108)
by 0x4A14070: mapi_execute_internal (Mapi.mx:3303)
by 0x4A142CC: mapi_query (Mapi.mx:3340)
by 0x400D9F: main (smack01.c:70)
----------------------------------------------------------------------
Comment By: Marcin Zukowski (e-r00)
Date: 2006-06-08 05:39
Message:
Logged In: YES
user_id=607094
I reran the experiments with 100K print(new(int,int)) queries.
The original error disappeared, but there are still some
leaks that seem related to SSL (?), see attached leak-client.
On the server side some memory might be lost as well, see
leak-server.
But it seems there are no leaks that increase with the
number of queries, which at least is a good thing.
I will check with an increasing number of connections now.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-05-31 08:08
Message:
Logged In: YES
user_id=43607
I checked in a fix. Can you recheck?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1498247&group_id=56967
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
