Memory leaking..

[gNash]

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char * strclear(const char *str)
{
char *string;
string=(char *)malloc(strlen(str)+1);
strcpy(string,str);
return string;
}


int main()
{
char *str="Five pineapples";
char *string;
string=strclear(str);
printf ("The string is %s\n",string);
free(string);
return 0;
}

Please refer above program for my question..

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?

2. Since i assign value of heap memory starting address and calling
free it is not freed.. why?

3. Could you any one please tell me how can i free the memory which
has been allocated dynamically by another function. without using any
globel variable?

Please help me ..
Thanks in advance,
Ganesh

 

[Ian Collins]

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char * strclear(const char *str)
{
char *string;
string=(char *)malloc(strlen(str)+1);

Please drop the cast and you may as well initialise string where it is
declared.

strcpy(string,str);
return string;
}


int main()
{
char *str="Five pineapples";
char *string;
string=strclear(str);
printf ("The string is %s\n",string);
free(string);
return 0;
}

Please refer above program for my question..

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?
No.

2. Since i assign value of heap memory starting address and calling
free it is not freed.. why?

It is freed.

 

[gNash]

Please drop the cast and you may as well initialise string where it is
declared.







It is freed.

Thankyou Ian Collins.. but i not getting message from valgrind as "all
heap memory are freed " it is saying "16 bytes are still reachable "
what it mean?

Please explain me..

 

[Richard Heathfield]

gNash said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char * strclear(const char *str)
{
char *string;
string=(char *)malloc(strlen(str)+1);
strcpy(string,str);
return string;
}

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */
}
return string;
}

[1] - str followed by a-z is "reserved for external use" by the
implementation, so don't use it in your own function names.
[2] - nesting the strlen in the malloc is fine, but if you choose to go the
memcpy route (see [5]), you'll want to cache this value.
[3] - no need to cast the return value of malloc, although *in this case*
your cast did no actual damage concealment, since you remembered to
#include <stdlib.h>, so no harm done on this occasion.
[4] - malloc can fail. Check that it doesn't before trusting the result.
[5] - if logic were any guide, it would make sense for memcpy to perform
the copy faster than strcpy. In practice, it seems to depend on the
implementation and to some extent on the length of the string. So this and
the preparatory step [2], above, are the bits that I'm simply mentioning
for consideration, rather than positively recommending.

int main()
{
char *str="Five pineapples";
char *string;
string=strclear(str);

See [1] above.

printf ("The string is %s\n",string);

Check for NULL:

if(string != NULL)
{
printf("The string is %s\n", string);
free(string);
}

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?

The program you showed has no leak.

2. Since i assign value of heap memory starting address and calling
free it is not freed.. why?

The program has no mechanism to detect whether that claim is correct.

3. Could you any one please tell me how can i free the memory which
has been allocated dynamically by another function. without using any
globel variable?

You already know how to do it. You've already done it. If valgrind is
behaving as you say on the program you show, then valgrind is wrong or
your implementation is sub-optimal.

 

[Ian Collins]

*Please* don't quote signatures.

Thankyou Ian Collins.. but i not getting message from valgrind as "all
heap memory are freed " it is saying "16 bytes are still reachable "
what it mean?

Please explain me..

I've no idea, never having used valgrind. All I can say is it is wrong.

 

[gNash]

gNash said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char * strclear(const char *str)
{
char *string;
string=(char *)malloc(strlen(str)+1);
strcpy(string,str);
return string;
}

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */
}
return string;

}

[1] - str followed by a-z is "reserved for external use" by the
implementation, so don't use it in your own function names.
[2] - nesting the strlen in the malloc is fine, but if you choose to go the
memcpy route (see [5]), you'll want to cache this value.
[3] - no need to cast the return value of malloc, although *in this case*
your cast did no actual damage concealment, since you remembered to
#include <stdlib.h>, so no harm done on this occasion.
[4] - malloc can fail. Check that it doesn't before trusting the result.
[5] - if logic were any guide, it would make sense for memcpy to perform
the copy faster than strcpy. In practice, it seems to depend on the
implementation and to some extent on the length of the string. So this and
the preparatory step [2], above, are the bits that I'm simply mentioning
for consideration, rather than positively recommending.

int main()
{
char *str="Five pineapples";
char *string;
string=strclear(str);

See [1] above.

printf ("The string is %s\n",string);

Check for NULL:

if(string != NULL)
{
printf("The string is %s\n", string);
free(string);

}

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?

The program you showed has no leak.

2. Since i assign value of heap memory starting address and calling
free it is not freed.. why?

The program has no mechanism to detect whether that claim is correct.

3. Could you any one please tell me how can i free the memory which
has been allocated dynamically by another function. without using any
globel variable?

You already know how to do it. You've already done it. If valgrind is
behaving as you say on the program you show, then valgrind is wrong or
your implementation is sub-optimal.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

thanks a lot Mr. Richared Heathfield. thanks for your information for
[1] too.

 

[Nick Keighley]

Richard Heathfield wrote:

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */

where does string get terminated?

}
return string;
}

<snip>

If I want to copy a string I use strcpy(). That way I avoid failing to
put the nul terminator in...

 

[Mark Bluemel]

Richard Heathfield wrote:

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */

where does string get terminated?

What is the value of len?

 

[Nick Keighley]

Richard Heathfield wrote:

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */

where does string get terminated?

What is the value of len?

brain fart. it wasn't the value of len that fooled me,
I failed to realise that its copying an already correctly
terminated string.

And I realised that about 1ns *after* I hit the post button.

<mumble> I *still* think strcpy() is better </mumble>

 

[Chris Dollin]

Richard Heathfield wrote:

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */

where does string get terminated?

In the `memcpy`, which copies `len` bytes, where `len` is /one more than/
the length of the string and hence includes the nul byte. This is also
why the `malloc` allocates enough space for the entire terminated string.

 

[Chris Dollin]

And I realised that about 1ns *after* I hit the post button.

Ha! I realise things like that /as I press the button/!

I win! Wait ... that's a good thing, right? (fxost) Oops.

 

[Guest]

I've no idea, never having used valgrind. All I can say is it is wrong.

If you've no idea what something means, you cannot know that it is
wrong. (But of course you can say it regardless.)

 

[Philip Potter]

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?

<OT>
Valgrind messages require some interpreting. There are four classes of
unfreed memory at the end of the program:

* Definitely lost (these are memory leaks for sure)
* Possibly lost (these are probably memory leaks, but may not be)
* Still reachable (these are probably not memory leaks and can be ignored)
* Supressed (valgrind sometimes finds "false positives" in library
functions. False positives that valgrind is aware of producing are
filtered into this category.)

For more info, ask in (I think) comp.unix.programmer or see the valgrind
website. The quick start guide to memcheck is very good.

In any case, valgrind is not wrong, though it could be described as
misleading. But if you don't read the documentation of your tool, how do
you expect to understand it?
</OT>

 

[Ben Bacarisse]

Richard Heathfield wrote:

<snip>

Better (or at least different!):

char *clearstr(const char *str) /* [1] */
{
size_t len = strlen(str) + 1; /* [2] */
char *string = malloc(len); /* [3] */
if(string != NULL) /* [4] */
{
memcpy(string, str, len); /* [5] */

where does string get terminated?

What is the value of len?

brain fart.

Having both fooled and been fooled by a similar issue, I prefer to
avoid 'len', 'length' and even 'l' for quantities that include the
terminator. Names liked to 'size' might be better.

it wasn't the value of len that fooled me,
I failed to realise that its copying an already correctly
terminated string.

OK, but I still wanted to make the above point!

 

[Ben Bacarisse]

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?

No, and if I copy, compile and run your code on my system, valgrind
says:

==7667== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==7667== malloc/free: in use at exit: 0 bytes in 0 blocks.
==7667== malloc/free: 1 allocs, 1 frees, 16 bytes allocated.
==7667== For counts of detected errors, rerun with: -v
==7667== All heap blocks were freed -- no leaks are possible.

so you are chasing a phantom problem. There is none.

 

[Richard]

If you've no idea what something means, you cannot know that it is
wrong. (But of course you can say it regardless.)

He was referring to the non pertinent parts of the program being "wrong"
- well not standard C. The cast did nothing wrong with regard to the
rest of the program. The moving of the malloc to the declaration line
was equally as non contributory to the question but simply made for
tighter cleaner code.

 

[Kenneth Brody]

gNash wrote: [... snip code ...]

Please refer above program for my question..

1. When i run with valgrid i got message as "16 byts in 1 block still
reachable". I think memory is leaking in the program. Am i right?
No.

2. Since i assign value of heap memory starting address and calling
free it is not freed.. why?

It is freed.

Thankyou Ian Collins.. but i not getting message from valgrind as "all
heap memory are freed " it is saying "16 bytes are still reachable "
what it mean?

Please explain me..

I've never used valgrind, but...

The code you posted frees everything that it mallocs.

Is it possible that the runtime startup code allocated something
that wasn't freed, and it's this block that's being reported?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Jack Klein]

If you've no idea what something means, you cannot know that it is
wrong. (But of course you can say it regardless.)

Yes, he can. As far as the C language is concerned, and that's the
only thing that counts here, free() was properly called on a pointer
returned from malloc(). Since the free() function cannot fail if
called correctly, as it is in this case, the memory was freed.

Neither Ian nor I have to know much about valgrind, the Magna Carta,
or a Comcast commercial featuring the Slowskys, to state that if they
say this memory was not freed, the are wrong.

The memory was freed in the only context that matters in this group.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Pietro Cerutti]

[5] - if logic were any guide, it would make sense for memcpy to perform
the copy faster than strcpy.

Which logic would say so?

 

[Richard Heathfield]

[5] - if logic were any guide, it would make sense for memcpy to perform
the copy faster than strcpy.

Which logic would say so?

With memcpy, you know the length in advance, so you can perform
optimisations such as copying four, eight, or even more bytes at a time,
whereas with strcpy that's a lot harder because you have to check for the
null terminator all the time. So you'd *expect* memcpy to be faster. In
practice, it need not be, and sometimes isn't.