| View previous topic :: View next topic |
| Author |
Message |
NoZ
Tux's lil' helper
Joined: 26 Oct 2004
Posts: 93
Location: Montpellier/France
|
 Posted: Wed Oct 12, 2005 2:20 pm Post subject: C++ memory management problem |
 |
|
I have a problem when deleting array of char...
Example :
int *toto = new int[ ... ] ;
...
delete[] toto ;
works fine... the memory is freeed, but when I do :
char *toto = new char[ ... ] ;
...
delete[] toto ;
the memory doesn't seem to be freeed (when I look the process size...)
Same thing with the string class.
Do someone know why ?
I'm running a ~x86 2005.1 under colinux. |
|
| Back to top |
|
 |
dmitchell
Veteran
Joined: 17 May 2003
Posts: 1159
Location: Austin, Texas
|
| Posted: Wed Oct 12, 2005 3:35 pm Post subject: |
|
|
What does valgrind say?
_________________
Your argument is invalid. |
|
| Back to top |
|
|
NoZ
Tux's lil' helper
Joined: 26 Oct 2004
Posts: 93
Location: Montpellier/France
|
| Posted: Wed Oct 12, 2005 4:25 pm Post subject: |
|
|
Here's my test code :
| Code: | #include <stdlib.h>
#include <stdio.h>
#include <iostream>
using namespace std ;
//------------------------------------------------------------------------
int main( int argc , char ** argv )
{
int SIZE = 5000000 ;
int i = 0 ;
int t = 0 ;
char ** tab = new char*[ SIZE ] ;
for (i = 0 ; i < SIZE ; i ++ )
{
tab[ i ] = new char[ 10 ] ;
strcpy( tab[ i ] , "hophophop" ) ;
}
cin >> t ;
for (i = 0 ; i < SIZE ; i ++ )
{
delete[] tab[ i ] ;
}
delete[] tab ;
cin >> t ;
return 0 ;
}
//------------------------------------------------------------------------ |
Before the first cin, i do :
| Code: | # ps aux
...
noz 5718 4.0 19.0 100040 98500 pts/1 S+ 18:07 0:01 sdupdate
... |
Before the second, i try again :
| Code: | | noz 5718 1.9 15.3 80508 79000 pts/1 S+ 18:07 0:02 sdupdate |
...is it normal ? When I test that with something else than char* ... it free all the memory... not just a part.
I alsa tried to see what happened while the execution with free -m...
| Code: | // before the start
noz@coMahoro ~ $ free -m
total used free shared buffers cached
Mem: 504 18 485 0 0 7
-/+ buffers/cache: 9 494
Swap: 511 3 508
// before the first cin
noz@coMahoro ~ $ free -m
total used free shared buffers cached
Mem: 504 113 390 0 0 7
-/+ buffers/cache: 105 398
Swap: 511 3 508
// before the second cin
noz@coMahoro ~ $ free -m
total used free shared buffers cached
Mem: 504 94 409 0 0 7
-/+ buffers/cache: 86 417
Swap: 511 3 508
// after the execution
noz@coMahoro ~ $ free -m
total used free shared buffers cached
Mem: 504 18 485 0 0 7
-/+ buffers/cache: 9 494
Swap: 511 3 508 |
The result of valgrind (with SIZE=500000) :
| Code: | noz@coMahoro ~/cpp/dev/sdupdate $ valgrind --leak-check=yes sdupdate
==5847== Memcheck, a memory error detector.
==5847== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==5847== Using LibVEX rev 1367, a library for dynamic binary translation.
==5847== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==5847== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==5847== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==5847== For more details, rerun with: -v
==5847==
1
2
==5847==
==5847== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 3)
==5847== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5847== malloc/free: 500001 allocs, 500001 frees, 7000000 bytes allocated.
==5847== For counts of detected errors, rerun with: -v
==5847== No malloc'd blocks -- no leaks are possible. |
.... I need many memory for this program ... WHAT'S THE PROBLEM ?????  |
|
| Back to top |
|
|
NoZ
Tux's lil' helper
Joined: 26 Oct 2004
Posts: 93
Location: Montpellier/France
|
| Posted: Wed Oct 12, 2005 7:59 pm Post subject: |
|
|
There's obviously a problem with the unstable Gentoo......... :'(
I just installed a small old Debian under colinux to test...... and it works. It's really weird :/
--> https://bugs.gentoo.org/show_bug.cgi?id=109049 |
|
| Back to top |
|
|
quickshiftin
Guru
Joined: 27 Jul 2004
Posts: 345
Location: Denver, CO
|
| Posted: Thu Oct 13, 2005 5:20 am Post subject: |
|
|
i repeated the same experiment on my gentoo machine and found out you are right about one thing, for some reason all the memory is not returned with a call to delete. however i ran the test code with int as well and i get the same result. also i ran the test code (exactly what you have in your earlier post) on a red hat box only to get the same results.
the issue is a c++ thing, what it is im not yet sure, but there is nothing wrong w/ gentoo, it certainly is not unstable.
i will try to solve the problem and post again |
|
| Back to top |
|
|
teknomage1
Veteran
Joined: 05 Aug 2003
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Thu Oct 13, 2005 5:49 am Post subject: |
|
|
| free is a rather unreliable estimate of how much memory is available to the system due to the way linux agressively caches. There should be a couple of threads from I think 2 years ago on the subject. |
|
| Back to top |
|
|
didl
Retired Dev
Joined: 09 Sep 2003
Posts: 1106
Location: Pittsburgh, PA
|
| Posted: Thu Oct 13, 2005 2:17 pm Post subject: |
|
|
Even though I am not able to give a concrete answer, I agree with
teknomage1. The fact that free shows unreleased memory does
not mean that your code hasn't properly released its resources,
but rather that the kernel has decided to keep the memory in
cache. The difference between your int and char arrays is their
vastly different size, hence the kernel will likely make different
caching decisions in both cases.
Why don't you use gdb to step through your code to
see what's going on? |
|
| Back to top |
|
|
dmitchell
Veteran
Joined: 17 May 2003
Posts: 1159
Location: Austin, Texas
|
| Posted: Thu Oct 13, 2005 4:33 pm Post subject: |
|
|
I hold the same view as the above: your code is correct, so the issue is likely with OS caching. My guess is that the kernel has noticed your program allocating lots of memory and is trying to optimize for that by keeping the memory available. If the memory were not actually being released, valgrind would report it.
_________________
Your argument is invalid. |
|
| Back to top |
|
|
|
Portage & Programming
