By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,418 Members | 1,104 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,418 IT Pros & Developers. It's quick & easy.

[HELP] Application Process Size in UNIX Enironment

P: n/a
Hi folks,
Recently, I am investigatin a memory leak issue.
I have written a simple C++ program and a Perl script to test on UNIX
environment machine.
I do a for loop to new up 20 char of size 32768 bytes, then delete
them. Please see below:

//// part of the code start ////
for (i=0; i<20; i++) {
ptrA[i] = new (std::nothrow) char[32768];
if (ptrA[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrA[i];
ptrA[i] = NULL;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=0; i<20; i++) {
ptrB[i] = new (std::nothrow) int(1863);
if (ptrB[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrB[i];
ptrB[i] = 0;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
//// part of the code end ////

And, following is my log been captured:
Tue Jul 4 07:01:25 CDT 2006 1613824 prog_init
Tue Jul 4 07:01:25 CDT 2006 1646592 Rnd_0_new_up_ptrA[0]
Tue Jul 4 07:01:25 CDT 2006 1679360 Rnd_0_new_up_ptrA[1]
Tue Jul 4 07:01:25 CDT 2006 1712128 Rnd_0_new_up_ptrA[2]
Tue Jul 4 07:01:25 CDT 2006 1744896 Rnd_0_new_up_ptrA[3]
Tue Jul 4 07:01:25 CDT 2006 1777664 Rnd_0_new_up_ptrA[4]
Tue Jul 4 07:01:25 CDT 2006 1810432 Rnd_0_new_up_ptrA[5]
Tue Jul 4 07:01:25 CDT 2006 1843200 Rnd_0_new_up_ptrA[6]
Tue Jul 4 07:01:25 CDT 2006 1875968 Rnd_0_new_up_ptrA[7]
Tue Jul 4 07:01:25 CDT 2006 1908736 Rnd_0_new_up_ptrA[8]
Tue Jul 4 07:01:25 CDT 2006 1941504 Rnd_0_new_up_ptrA[9]
Tue Jul 4 07:01:25 CDT 2006 1974272 Rnd_0_new_up_ptrA[10]
Tue Jul 4 07:01:25 CDT 2006 2007040 Rnd_0_new_up_ptrA[11]
Tue Jul 4 07:01:25 CDT 2006 2039808 Rnd_0_new_up_ptrA[12]
Tue Jul 4 07:01:26 CDT 2006 2072576 Rnd_0_new_up_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2105344 Rnd_0_new_up_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2138112 Rnd_0_new_up_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2170880 Rnd_0_new_up_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2203648 Rnd_0_new_up_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2236416 Rnd_0_new_up_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_new_up_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[12]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[11]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[10]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[9]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[8]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[7]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[6]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[5]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[4]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[3]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[2]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[2]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[3]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[4]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[5]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[6]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[7]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[8]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[9]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[10]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[11]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[12]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[13]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[14]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[15]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[16]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[16]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[15]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[14]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[13]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[12]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[11]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[10]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[9]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[8]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[7]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[6]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[5]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[4]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[3]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[2]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[1]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[0]
I noticed that the process size only increase for the first 20 new-ups
for ptrA though I loop it for a few rounds.
Then, come to delete, the process size never decreased.
After that, for newing-up ptrB, there is no increasing for process size
also (is this normal?).
Finally, delete ptrB still maintain the process size without
decreasing.

I have 2 question here:
a) When 'delete' a new-up pointer in UNIX environment, the process size
will not be decreased?
b) From my log, why when newing-up my ptrB, there is no increasing
size?

Hope you guys understand my problem. Looking for UNIX or Memory expert
to kill my doubts.
Thanks.

regards,
Vynce

Jul 5 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
asimorio wrote:
Hi folks,
Recently, I am investigatin a memory leak issue.
I have written a simple C++ program and a Perl script to test on UNIX
environment machine.
I do a for loop to new up 20 char of size 32768 bytes, then delete
them. Please see below:

//// part of the code start ////
for (i=0; i<20; i++) {
ptrA[i] = new (std::nothrow) char[32768];
if (ptrA[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrA[i];
ptrA[i] = NULL;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=0; i<20; i++) {
ptrB[i] = new (std::nothrow) int(1863);
if (ptrB[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrB[i];
ptrB[i] = 0;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
//// part of the code end ////

And, following is my log been captured:
Tue Jul 4 07:01:25 CDT 2006 1613824 prog_init
Tue Jul 4 07:01:25 CDT 2006 1646592 Rnd_0_new_up_ptrA[0]
Tue Jul 4 07:01:25 CDT 2006 1679360 Rnd_0_new_up_ptrA[1]
Tue Jul 4 07:01:25 CDT 2006 1712128 Rnd_0_new_up_ptrA[2]
Tue Jul 4 07:01:25 CDT 2006 1744896 Rnd_0_new_up_ptrA[3]
Tue Jul 4 07:01:25 CDT 2006 1777664 Rnd_0_new_up_ptrA[4]
Tue Jul 4 07:01:25 CDT 2006 1810432 Rnd_0_new_up_ptrA[5]
Tue Jul 4 07:01:25 CDT 2006 1843200 Rnd_0_new_up_ptrA[6]
Tue Jul 4 07:01:25 CDT 2006 1875968 Rnd_0_new_up_ptrA[7]
Tue Jul 4 07:01:25 CDT 2006 1908736 Rnd_0_new_up_ptrA[8]
Tue Jul 4 07:01:25 CDT 2006 1941504 Rnd_0_new_up_ptrA[9]
Tue Jul 4 07:01:25 CDT 2006 1974272 Rnd_0_new_up_ptrA[10]
Tue Jul 4 07:01:25 CDT 2006 2007040 Rnd_0_new_up_ptrA[11]
Tue Jul 4 07:01:25 CDT 2006 2039808 Rnd_0_new_up_ptrA[12]
Tue Jul 4 07:01:26 CDT 2006 2072576 Rnd_0_new_up_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2105344 Rnd_0_new_up_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2138112 Rnd_0_new_up_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2170880 Rnd_0_new_up_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2203648 Rnd_0_new_up_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2236416 Rnd_0_new_up_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_new_up_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[12]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[11]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[10]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[9]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[8]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[7]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[6]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[5]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[4]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[3]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[2]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[2]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[3]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[4]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[5]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[6]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[7]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[8]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[9]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[10]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[11]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[12]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[13]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[14]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[15]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[16]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[16]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[15]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[14]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[13]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[12]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[11]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[10]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[9]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[8]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[7]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[6]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[5]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[4]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[3]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[2]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[1]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[0]
I noticed that the process size only increase for the first 20 new-ups
for ptrA though I loop it for a few rounds.
Then, come to delete, the process size never decreased.
After that, for newing-up ptrB, there is no increasing for process size
also (is this normal?).
Finally, delete ptrB still maintain the process size without
decreasing.

I have 2 question here:
a) When 'delete' a new-up pointer in UNIX environment, the process size
will not be decreased?
b) From my log, why when newing-up my ptrB, there is no increasing
size?

Hope you guys understand my problem. Looking for UNIX or Memory expert
to kill my doubts.
Thanks.

regards,
Vynce
Well, the deleted memory is still in your app's process space (in the
free-list) and will be reused to satisfy later allocations. Only when
the app terminates will the memory be returned to the OS.

Larry
Jul 5 '06 #2

P: n/a
asimorio wrote:

Stuff that should go to comp.unix.programmer.
I noticed that the process size only increase for the first 20 new-ups
for ptrA though I loop it for a few rounds.
Then, come to delete, the process size never decreased.
After that, for newing-up ptrB, there is no increasing for process size
also (is this normal?).
Yes - repost to the above group for more comprehensive answers. If that
group had an FAQ - this would be on it!

--
Ian Collins.
Jul 5 '06 #3

P: n/a
Thanks Collins.
I will try to re-post to that group.

Ian Collins wrote:
asimorio wrote:

Stuff that should go to comp.unix.programmer.
I noticed that the process size only increase for the first 20 new-ups
for ptrA though I loop it for a few rounds.
Then, come to delete, the process size never decreased.
After that, for newing-up ptrB, there is no increasing for process size
also (is this normal?).

Yes - repost to the above group for more comprehensive answers. If that
group had an FAQ - this would be on it!

--
Ian Collins.
Jul 5 '06 #4

P: n/a
Hi Larry,
do you have any documentation or website that showing the "re-use"
thing by UNIX?
thanks.
Larry I Smith wrote:
>
Well, the deleted memory is still in your app's process space (in the
free-list) and will be reused to satisfy later allocations. Only when
the app terminates will the memory be returned to the OS.

Larry
Jul 5 '06 #5

P: n/a
asimorio wrote:
Hi folks,
Recently, I am investigatin a memory leak issue.
I have written a simple C++ program and a Perl script to test on UNIX
environment machine.
I do a for loop to new up 20 char of size 32768 bytes, then delete
them. Please see below:

//// part of the code start ////
for (i=0; i<20; i++) {
ptrA[i] = new (std::nothrow) char[32768];
if (ptrA[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrA[i];
ptrA[i] = NULL;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=0; i<20; i++) {
ptrB[i] = new (std::nothrow) int(1863);
if (ptrB[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrB[i];
ptrB[i] = 0;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrB[%d]
%d",j, i, pid);
system(strCmd);
}
//// part of the code end ////

And, following is my log been captured:
Tue Jul 4 07:01:25 CDT 2006 1613824 prog_init
Tue Jul 4 07:01:25 CDT 2006 1646592 Rnd_0_new_up_ptrA[0]
Tue Jul 4 07:01:25 CDT 2006 1679360 Rnd_0_new_up_ptrA[1]
Tue Jul 4 07:01:25 CDT 2006 1712128 Rnd_0_new_up_ptrA[2]
Tue Jul 4 07:01:25 CDT 2006 1744896 Rnd_0_new_up_ptrA[3]
Tue Jul 4 07:01:25 CDT 2006 1777664 Rnd_0_new_up_ptrA[4]
Tue Jul 4 07:01:25 CDT 2006 1810432 Rnd_0_new_up_ptrA[5]
Tue Jul 4 07:01:25 CDT 2006 1843200 Rnd_0_new_up_ptrA[6]
Tue Jul 4 07:01:25 CDT 2006 1875968 Rnd_0_new_up_ptrA[7]
Tue Jul 4 07:01:25 CDT 2006 1908736 Rnd_0_new_up_ptrA[8]
Tue Jul 4 07:01:25 CDT 2006 1941504 Rnd_0_new_up_ptrA[9]
Tue Jul 4 07:01:25 CDT 2006 1974272 Rnd_0_new_up_ptrA[10]
Tue Jul 4 07:01:25 CDT 2006 2007040 Rnd_0_new_up_ptrA[11]
Tue Jul 4 07:01:25 CDT 2006 2039808 Rnd_0_new_up_ptrA[12]
Tue Jul 4 07:01:26 CDT 2006 2072576 Rnd_0_new_up_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2105344 Rnd_0_new_up_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2138112 Rnd_0_new_up_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2170880 Rnd_0_new_up_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2203648 Rnd_0_new_up_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2236416 Rnd_0_new_up_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_new_up_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[19]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[18]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[17]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[16]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[15]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[14]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[13]
Tue Jul 4 07:01:26 CDT 2006 2269184 Rnd_0_delete_ptrA[12]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[11]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[10]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[9]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[8]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[7]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[6]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[5]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[4]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[3]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[2]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_delete_ptrA[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[0]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[1]
Tue Jul 4 07:01:27 CDT 2006 2269184 Rnd_0_new_up_ptrB[2]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[3]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[4]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[5]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[6]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[7]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[8]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[9]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[10]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[11]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[12]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[13]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[14]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[15]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[16]
Tue Jul 4 07:01:28 CDT 2006 2269184 Rnd_0_new_up_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_new_up_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[19]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[18]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[17]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[16]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[15]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[14]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[13]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[12]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[11]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[10]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[9]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[8]
Tue Jul 4 07:01:29 CDT 2006 2269184 Rnd_0_delete_ptrB[7]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[6]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[5]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[4]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[3]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[2]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[1]
Tue Jul 4 07:01:30 CDT 2006 2269184 Rnd_0_delete_ptrB[0]
I noticed that the process size only increase for the first 20 new-ups
for ptrA though I loop it for a few rounds.
Then, come to delete, the process size never decreased.
After that, for newing-up ptrB, there is no increasing for process size
also (is this normal?).
Finally, delete ptrB still maintain the process size without
decreasing.

I have 2 question here:
a) When 'delete' a new-up pointer in UNIX environment, the process size
will not be decreased?
That is up to the implementation. A C++ compiler is free to generate code
for new and delete that keep memory around for reuse by the program. There
is no requirement that memory be returned to the OS.

Sometimes, an implementation makes such decisions based upon the size of the
memory chunks you allocate. Try allocating chunks of size 200000 and see
what happens.
b) From my log, why when newing-up my ptrB, there is no increasing
size?
That is because you called delete before. The memory is being reused.

Best

Kai-Uwe Bux
Jul 5 '06 #6

P: n/a
Just curious
Should <<<----------------------------------------------- this line not
be

delete []ptrA[i];

//// part of the code start ////
for (i=0; i<20; i++) {
ptrA[i] = new (std::nothrow) char[32768];
if (ptrA[i] == 0)
return 1;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_new_up_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
for (i=19; i>=0; i--) {
delete ptrA[i]; //
<<<-----------------------------------------------
ptrA[i] = NULL;
//chk size here
sprintf (strCmd, "perl csize.pl Rnd_%d_delete_ptrA[%d]
%d",j, i, pid);
system(strCmd);
}
same for ptrB

Jul 5 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.