Releasing Calloc memory

[Raj Pashwar]

Hello friends
How shall I release memory from Calloc? I thought it would be Free, but
this gives Segmention Fault. I tried if there would be a Cfree function
but no such can be found by the compiler.

Best regards

 

[Barry Schwarz]

Hello friends
How shall I release memory from Calloc? I thought it would be Free, but
this gives Segmention Fault. I tried if there would be a Cfree function
but no such can be found by the compiler.

free (there is no Free) is the correct function. If your call to free
results in a segmentation fault, then you have an error in your code.
Some of the most common errors are :

Passing an address to free that is not the value returned by
malloc, calloc, or realloc.

Accessing beyond the end of an allocated area (buffer overrun).

If you want help, you will need to show your code.

 

[Ian Collins]

Hello friends
How shall I release memory from Calloc? I thought it would be Free, but
this gives Segmention Fault. I tried if there would be a Cfree function
but no such can be found by the compiler.

Assuming you mean "calloc" and "free", then yes, you should use free and
your bug (probable memory corruption) lies elsewhere. If not, what are
Calloc and Free?

 

[Raj Pashwar]

free (there is no Free) is the correct function. If your call to free
results in a segmentation fault, then you have an error in your code.
Some of the most common errors are :

Passing an address to free that is not the value returned by
malloc, calloc, or realloc.

Accessing beyond the end of an allocated area (buffer overrun).

If you want help, you will need to show your code.

Sure, code is

#include<memory.h>
....
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
....
free(ip); // gives segmention fault

or

cfree(ip); // gives compile error

The Free works fine with other Malloc memory, but not this Calloc call :-(

Best regards

 

[Lanarcam]

Le 13/04/2012 23:47, Raj Pashwar a écrit :

Sure, code is

#include<memory.h>
...
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
...
free(ip); // gives segmention fault

or

cfree(ip); // gives compile error

The Free works fine with other Malloc memory, but not this Calloc call :-(

Have you checked the value of ip after the call to calloc?
What is the value of ARYSIZ?

 

[John Gordon]

int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
...
free(ip); // gives segmention fault

There's nothing wrong with this code. The fault must be in the code
you haven't shown us.

Unfortunately, the C dynamic memory allocation system is very fragile.
If you do one little thing wrong, such as overflowing a buffer or free'ing
an invalid pointer, all bets are off. The whole program can crash at any
point after that, even when excuting code (such as your example) that is
correct by itself.

 

[James Kuyper]

Sure, code is

#include<memory.h>
...
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
...
free(ip); // gives segmention fault

or

cfree(ip); // gives compile error

The problem lies somewhere in the part of the program that you did NOT
provide us. This is normal and to be expected: if you don't know what
the problem is, you can't expect to know which part of the program is
causing the problem.

In order for us to be able to help you, you must provide a COMPLETE
program that we can compile and test. You should identify which compiler
you're using, and whatever options you turned on (or off) when using
that compiler. The program should be as small as possible, so I'd
recommend cutting out large chunks of the program, and then testing to
see if it still demonstrates the problem. If it doesn't, put that chunk
of the program back in, and remove a different chunk. When you've got
the program down to a reasonable size, and you've verified that it still
demonstrates the problem, please post it to this newsgroup.

By the way: don't be surprised if you discover what the problem is
yourself, as a side effect of performing such trimming. This is a very
time consuming method for debugging a program, but done properly it is
very reliable.

 

[Edward A. Falk]

int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)

It's *probably* not your problem, but that "4" should be "sizeof(int)"
or "sizeof(*ip)". You can't always assume that an int is four bytes.

 

[Keith Thompson]

Sure, code is

#include<memory.h>
...
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
...
free(ip); // gives segmention fault

or

cfree(ip); // gives compile error

The Free works fine with other Malloc memory, but not this Calloc call :-(

No, that's not your code. That's a few scattered lines of your code
with "..." inserted between them. There's not enough information
here to tell what's causing the symptom you're seeing.

Try taking a copy of your actual code and removing piece of it,
narrowing it down to a small compilable program that exhibits the
problem you're seeing. You should be able to get it down to, say,
10-20 lines. You might even be able to solve the problem yourself
while you're doing this. If not, feel free to post a followup here.

But I can point out a few problems.

<memory.h> is not a standard header. The calloc and free functions
are declared in <stdlib.h>; you need to have "#include <stdlib.h>"
at the top of your source file. (There is a <memory.h> header on
my system, but I've never used it.)

Names in all-caps, like ARYSIZ, are usually macros; I'd expect
something like

#define ARYSIZE 1024

But you say it "denotes array size (read from file)". If it's a
variable, just as a matter of style and legibility, it shouldn't
have an all-caps name.

There is no cfree function, so you can stop worrying about it.
The correct way to release memory allocated by calloc() is to
call free().

Consider whether you really need to use calloc() rather than
malloc(). The main difference between them is that calloc() sets the
allocated memory to all-bits-zero. That's typically not a useful
thing to do; in most cases, you just shouldn't be accessing array
elements that you haven't assigned values to. That's not to say
that you should *never* use calloc(), just that you should think
about whether you need it.

Finally, please don't refer to the calloc and free functions as
"Calloc" and "Free". C identifiers are case-sensitive. "Calloc",
and "Free", if they existed, would be two completely separate
functions. (I'll refrain from digressing about C90 external
identifier rules.) Don't capitalize C function names; just call
them by their names, "calloc" and "free" -- even if they're at the
beginning of a sentence.

 

[Johann Klammer]

On Fri, 13 Apr 2012 14:38:45 -0700, Barry Schwarz wrote:

Sure, code is

#include<memory.h>
...
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)

Things read from a file are often _waaay_ off. Make sure to check if
ARYSIZ is something sane and if(ip!=NULL). As a rule of thumb, you
should check _any_ values you get from the external world for sanity.
Also, use some allocation debugging library for developing, else you
_will_ end up with memory leaks(or worse) in your code.
libdmalloc seems to work fine. Others prefer valgrind.

...
free(ip); // gives segmention fault

This smells of heap corruption. May have happened at that calloc() above
or far before that...?

 

[Joe Pfeiffer]

free (there is no Free) is the correct function. If your call to free
results in a segmentation fault, then you have an error in your code.
Some of the most common errors are :

Passing an address to free that is not the value returned by
malloc, calloc, or realloc.

Accessing beyond the end of an allocated area (buffer overrun).

If you want help, you will need to show your code.

Note that on the second one, the crash may not happen when the buffer
overrun does: the buffer overrun can corrupt the free space pool,
causing a crash on a later malloc() or free() (or a host of other
situations).

A third one: free()ing the same block of memory a second time.

 

[Joe Pfeiffer]

Sure, code is

#include<memory.h>
...
int* ip=calloc(4,ARYSIZ); // ARYSIZ denotes array size (read from file)
...
free(ip); // gives segmention fault

It's a pretty safe bet your bug is somewhere in the "..." you didn't
share. Or else someplace else causing the free space pool to already be
corrupt before you called the function the calloc() occurs in.

or

cfree(ip); // gives compile error

quoting the cfree man page: "This function should never be used. Use
free(3) instead."

The Free works fine with other Malloc memory, but not this Calloc call :-(

Best regards

You might want to investigate the electric-fence library (it's a
dynamic memory allocation debugging aid).

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 13 ב×פריל 2012 22:39:23 UTC+1, מ×ת Ian Collins:

Assuming you mean "calloc" and "free", then yes, you should use free and
your bug (probable memory corruption) lies elsewhere. If not, what are
Calloc and Free?

Environments often provide malloc replacements. For instance in Matlab mex files (C functions called by Matlab) you have to call mxMalloc() and mxFree() for dynamic memory you pass back to Matlab. On Unix these are just aliases for malloc() and free(), but in Windows they have automatic garbage collection.

If Calloc() and Free() don't work exactly as calloc() and free() then someone is being perverse.

Visit my website. Check out the new data density program.
http://www.malcommclean.site11.com/www

 

[Joe Pfeiffer]

בת×ריך ×™×•× ×©×™×©×™, 13 ב×פריל 2012 22:39:23 UTC+1, מ×ת Ian Collins:
Environments often provide malloc replacements. For instance in Matlab mex files (C functions called by Matlab) you have to call mxMalloc() and mxFree() for dynamic memory you pass back to Matlab. On Unix these are just aliases for malloc() and free(), but in Windows they have automatic garbage collection.

If Calloc() and Free() don't work exactly as calloc() and free() then someone is being perverse.

I'm guessing the OP doesn't understand the importance of typing
*exactly* what he means if he wants people to help with bugs, and it's
really calloc() and free().

I got to the point that when students needed help debugging I wouldn't
even look at the listings they'd bring in. I'd demand they pop a shell
on my computer so I could look at what the code really said.

 

[Raj Pashwar]

In <[email protected]> Raj Pashwar


There's nothing wrong with this code. The fault must be in the code you
haven't shown us.

Unfortunately, the C dynamic memory allocation system is very fragile.
If you do one little thing wrong, such as overflowing a buffer or
free'ing an invalid pointer, all bets are off. The whole program can
crash at any point after that, even when excuting code (such as your
example) that is correct by itself.

OK, I have tried many many things and in the end I think I have now
worked out the problem, a simple bug: in my code I failed to properly
typecast the pointer from Calloc. The line now has
int* ip=(int*) calloc(4,ARYSIZ);
and I don't get the segmention fault anymore.

Thanks to all who have aided me here.

Best regards

 

[Ian Collins]

OK, I have tried many many things and in the end I think I have now
worked out the problem, a simple bug: in my code I failed to properly
typecast the pointer from Calloc.

It's "calloc", not "Calloc".

The line now has
int* ip=(int*) calloc(4,ARYSIZ);
and I don't get the segmention fault anymore.

That cast will make absolutely no difference, it is totally superfluous.

You must have fixed something else.

 

[James Kuyper]

....
OK, I have tried many many things ...

I notice that the one thing you did NOT try is to give us a copy of a
complete program demonstrating your problem. This is common behavior
among people who come here asking questions, but it still confuses me.
Giving us that program would have been the single most useful thing you
could have done to find out what's wrong with your code - why didn't you
do it?

... and in the end I think I have now
worked out the problem,

You haven't.

... a simple bug: in my code I failed to properly
typecast the pointer from Calloc. The line now has
int* ip=(int*) calloc(4,ARYSIZ);

That's not a bug. In fact, inserting such a cast is a bad idea in C code
(it's mandatory in C++, which is one of the bigger differences between
the two languages).

That cast specifies explicitly precisely the same conversion that
occurred implicitly before you added the cast. Therefore, unless your
code has a problem somewhere else, that cast should not have made any
difference in the behavior. Is is possible that you made some other
change at the same time?

You haven't actually solved your problem, you've just plastered it over
so it's harder to see.

If putting in that cast is in fact the only change you made, and it
removed a segmentation fault, that suggests what the real problem might
be. Does your code contain a line like the following:

#include <stdlib.h>

prior to the first call to calloc()? If not, that could be the real problem.

 

[Eric Sosman]

[...]
OK, I have tried many many things and in the end I think I have now
worked out the problem, a simple bug: in my code I failed to properly
typecast the pointer from Calloc. The line now has
int* ip=(int*) calloc(4,ARYSIZ);
and I don't get the segmention fault anymore.

Barring compiler bugs, that change cannot possibly have had
anything to do with anything. It just writes out explicitly the
exact same conversion the compiler would have done implicitly. It
is like changing `int x = sqrt(2.0);' to `int x = (int)sqrt(2.0);':
The conversion will occur, with or without the cast.

Compiler bugs do in fact occur, and there is a possibility that
you have been bitten by one and have stumbled upon a way to avoid
the fangs. But the possibility is of the same order as being
struck by lightning or winning the grand prize in the lottery, so
my strong suspicion is that you have made other changes that you
did not reveal.

In any event: Do NOT proceed on the assumption that adding a
cast fixes your problem; it is surpassingly unlikely that it did
any such thing.