Memory

[frei]

Hi!

Maybe a simple question...
If I've a program that allocates memory dynamically and runs for only a few seconds and terminates then:
Is the allocated memory still in use after terminating the program if I don't free it explicitly? Or is the memory being freed automatically by terminating the program?

Regards
Patrick

[Mick]

Depends on the OS...most OS's free the memory at process termination but you should be a good citizen and free it yourself.

[frei]

Hmm, I've a Linux as OS...
I already tried to free the memory, but it doesn't work correct. So I posted it here at Codeguru (http://www.codeguru.com/forum/showthread.php?t=349814), but the only one answer I got doesn't work... I get an error from the compiler.
Maybe you know more??

Thank you!
Patrick

[cilu]

Whatever dinamically memory you allocate, you must release it. C++ does not have a garbage collector to take care of that. If you were writting in Managed C++ (which I don't thinks it's the case), than the memory disposal would be taken care by the .NET runtime environment.

See this FAQ about memory leaks.

[SuperKoko]

the only one answer I got doesn't work... I get an error from the compiler.

Compilation errors are very good for programmers and should be considered as a blessing.
You just need to understand the compilation error.
If you don't understand the message, you can search in your compiler documentation to get a more detailed description.
If you still don't understand, you can post some code, and the error message, so some gurus could analyse the error.

Memory leaks are evil. Linux as Win32 automatically free memory allocated with malloc (because the virtual addressing space of the process is freed) when a program exits, but don't free shared resources.
Moreover some other platforms may not free automatically memory leaks.

[frei]

I don't know why it doesn't work, but I think the problem is caused due to the memory-RE-allocation in my program. What I did:
1) Allocating memory (e.g. y=50)
2) Re-allocating memory if a certain value is exceeded (e.g. y>50 -> the ney y = 100)
3) Free memory (100)
When I free the memory the error is reported exactly at the value where I did the reallocation, i.e. at y=50...
Does free maybe not "know" that it has now y=100 instead of 50??

[SuperKoko]

When you realloc some data, the block of data may be moved, and you must absolutely use the new pointer returned by realloc. The previous pointer is invalid after that.

[frei]

But when I realloc the memory, I'm using a new pointer as you can see in the code... I really don't known anymore why that's not working...
if (log_rec.resp_code==RC_NOTFOUND) {
u_long z = 1;
z = y;
int flag = 0;
while (z>0) {
if ( strcmp( respnotfound[z].respurl, log_rec.url ) == 0 ) {
respnotfound[z].count++;
flag = 1;
}
z-=1;
}
if (flag != 1) {
/* Realloc the memory if necessary */
if (y>=maxresp) {
void * new_ptr = realloc(respnotfound, sizeof(struct response_url) * (maxresp + INCRESP) );
if( new_ptr ) {
respnotfound = (struct response_url *) new_ptr;
strncpy(respnotfound[y].respurl,log_rec.url, MAXURL-1);
y+=1;
resp_counter+=1;
maxresp+=INCRESP;
}
else {
fprintf(stderr, "ERROR: Can't reallocate enough memory\n");
exit(0);
}
}
else {
strncpy(respnotfound[y].respurl,log_rec.url, MAXURL-1);
y+=1;
resp_counter+=1;
}
}
flag = 0;
}

[SuperKoko]

while (z>0) {
if ( strcmp( respnotfound[z].respurl, log_rec.url ) == 0 ) {
respnotfound[z].count++;
flag = 1;
}
z-=1;
}

This piece of code seems to be incorrect, because it uses respnotfound[y] which is invalid, and it does not look at respnotfound[0].
You should replace it by:

while (z>0) {z-=1;
if ( strcmp( respnotfound[z].respurl, log_rec.url ) == 0 ) {
respnotfound[z].count++;
flag = 1;break; // maybe you don't want this break, but if i understood correctly your code, it is highly probable that it just accelerates the process.
}
}


You can use ++ and -- instead of +=1 and -=1.
It is equivalent for the compiler, but maybe a little easier to read.
strncpy is dangerous, because the destination may be not null-terminated.
In fact, strcpy is as safe as strncpy in your program, or you can write a xstrncpy which calls strncpy, and put a null character at the end of the buffer.

u_long z = 1; // this assignment is useless
z = y;
int flag = 0;

I was not aware that you could declare some variables in a local block with C.
Or are you using C++?
In that case, you can write a class handling the addition of respnotfound structures, based on std::vector or std::deque, if possible.
You should also use bool flag instead of int flag.
But i suppose that it is hard to modify the design of your program.

[frei]

Hmm, I really think that the problem is caused by the realloc!!! I change now the code below, too (bold):

if (y>=maxresp) {
void * new_ptr = realloc(respnotfound, sizeof(struct response_url) * (maxresp + INCRESP) );
if( new_ptr ) {
respnotfound_tmp = (struct response_url *) new_ptr;
respnotfound = respnotfound_tmp;
strncpy(respnotfound[y].respurl,log_rec.url, MAXURL-1);
y+=1;
resp_counter+=1;
maxresp+=INCRESP;
}
else {
fprintf(stderr, "ERROR: Can't reallocate enough memory\n");
exit(0);
}
}
But when I free the memory with free (respnotfound); it still fails... Looks as if it finds the memory to free till the point where I reallocated it!
I was looking at a lot of sample code on the WWW but they also (re-)allocate the memory as I did...

[Paul McKenzie]

You're probably corrupting the heap in some other part of your program. The issue is what you are doing with this reallocated memory, not how you reallocated memory. You can reallocate just fine, if you then go and mess up the heap manager by overwriting array boundaries, use invalid pointers, etc. the call to free() (or any other function related to memory allocation/deallocation) may fail.

In the code you posted, you are using variables we have no idea what the values are in your call to realloc(). But again, even if these values are correct, my first point concerning what you're doing with the memory is just as, if not more important, then how you are allocating the memory.

Also, if this is a C++ program, why are you using 'C' techniques to allocate memory (i.e. malloc(), realloc(), etc.). Why not use new[], or better yet std::vector<char>?

Regards,

Paul McKenzie

[Paul McKenzie]

Looks as if it finds the memory to free till the point where I reallocated it! I was looking at a lot of sample code on the WWW but they also (re-)allocate the memory as I did...Write a simple program that uses realloc(). You will see that there is no rocket science involved. You just retain the pointer to whatever realloc() returns, and you free that pointer.

This (as my last post states) means that you are doing something to the memory in between your call to realloc() and free().

#include <stdlib.h>

int main()
{
int *p;
int *ptemp;
int i;
for (i = 0; i < 1000; ++i )
{
p = (int *)malloc(10 * sizeof(int));
ptemp = (int *)realloc(p, 20 * sizeof(int));
if ( ptemp )
p = ptemp;
// do (possibly illegal) things with p or some other variables
//....
free( p );
}
}

This code were there are 1,000 calls to realloc works fine by itself. If I now were to do (illegal) memory accesses during the lifetime of p, then I go and free() it, then this may cause a memory violation.

Regards,

Paul McKenzie

[Monk el]

After I read SuperKoko thread, i also realize how important the design process is and also fixed some mistakes in the code I have.

I would actually never try to be any harsh when seeing people write code that is so illegible, don't you find it hard, frei ?

As supperkoko mentioned, that coding style will make your life harder then, and if you still haven't found out the bug yet after what Paul already mention in his posts, be sure to have a book on debug techniques right next to you everytime you sit down and begin to type down similar long lines of code.

Using C mixed with C++ code is not what is expected by most developers, and this is why you might see Supperkoko's bolded letters, or Paul's suggestions...

They are just some explanations to make things Paul say much clearer, and I believe you solved your problem with Paul suggestions also.... Congratulations, anyway ;)


LE@Hohhaiho