[Q] Testing for malloc()

[Ian Roddis]

Hi all,

I've written some code to make a hash data structure and associated
funtions (insert, delete, search). In the delete function, I want to free()
the key and the associated value. But since I want to be able to use this
code, I can't discount the chance that the key or the value are static
values on the stack. If this is the case, then free() will (obviously) fail.

On Solaris <sys/ucontext.h> has a function stack_inbounds that will return
a non-zero value if the address passed to it is in the heap, but this
function isn't portable -- only Solaris implements it.

So the really short version of the question is: How can I test to see if a
pointer points to malloc() assigned space (on the heap) or is a static value
defined in the data stack?

Thanks in advance,
Ian

(e-mail address removed)

 

[Ian Roddis]

I just thought I'd post some code to make my problem a little clearer:

test.c:

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

int main() {
char *foo_string;

/* Test to free malloc assigned space */

if ( ! ( foo_string = malloc ( sizeof (char) * 10 ) ) ) {
printf ( "Could not allocate space\n" );
exit ( 1 );
}

free ( foo_string );

/* Test to free a static string */

foo_string = "Random drivel";

free ( foo_string );

printf ( "Completed Successfully\n" );
exit ( 0 );
}
/* END test.c */

$./test
*** malloc[1147]: Deallocation of a pointer not malloced: 0x1ff0; This could
be a double free(), or free() called with the middle of an allocated block;
Try setting environment variable MallocHelp to see tools to help debug
Completed Successfully
$

The program completed successfully, but with ugly error messages and messy
code. Is there any test I can perform on foo_string to see if I can free()
it or not?

Thanks again,
Ian

 

[Gordon Burditt]

I've written some code to make a hash data structure and associated

funtions (insert, delete, search). In the delete function, I want to free()
the key and the associated value. But since I want to be able to use this
code, I can't discount the chance that the key or the value are static
values on the stack. If this is the case, then free() will (obviously) fail.

free() is not guaranteed to fail obviously. free() may fail in a
subtle manner that is maximally embarassing or expensive (e.g. it
only fails in front of the customer or the chairman of the board.
Or it only fails when it is in production and then it shuts down
the power grid in several states or scatters pieces of spacecraft
over hundreds of miles).

On Solaris <sys/ucontext.h> has a function stack_inbounds that will return
a non-zero value if the address passed to it is in the heap, but this
function isn't portable -- only Solaris implements it.

Functions like this can get, um, "interesting" when you try to use
threads. Of course, those aren't standard either.

So the really short version of the question is: How can I test to see if a
pointer points to malloc() assigned space (on the heap) or is a static value
defined in the data stack?

You invoke the wrath of undefined behavior.

if ((void)fflush(++(void)main++)) {
/* variable was allocated from the toilet */
} else {
/* variable was allocated from the garbage dump */
}
is one way to make it fail at compile time so you'll know right
away that it won't work. I'm not aware of a system-specific way
to do this other than the one you mentioned for Solaris, and
a system on which malloc() always fails.

Oh, yes, there's more choices than this. The pointer can point to
malloc() assigned space, it could point to an automatic variable
(what stack?), it could point to static data in the program, or it
could point to static data in a shared library (which often blows
to bits system-specific assumptions about the addresses of "the
beginning and end of the data segment"). ANSI C does not provide
for shared libraries but it doesn't prohibit them either.

Or you make sure that all of the values are, in fact, allocated
with malloc() by making copies yourself. This, obviously, involves
a change in strategy for the caller of your function for freeing
allocated memory once.

Gordon L. Burditt

 

[Samuel Barber]

Bad design. If the caller allocates the memory, the caller should free
it. But if you really want to do this, simply document that the caller
must use malloc().

Sam

 

[Ian Roddis]

Thanks very much. This is the solution I'll use. Thanks very much for
everyone's input.

-Ian

 

[Ian Roddis]

And now I get to display my ignorance . Is there an easy way to determine
the size of the memory pointed to by a pointer?

/* begin hash_test.c */

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

int hash_add_item ( struct Hash *hash_ptr, char *key, void* contents ) {
char *key_copy;
void *contents_copy;

printf ( "Creating new contents of %d bytes\n", sizeof ( *contents ) );
if ( ! ( key_copy = malloc ( sizeof ( *contents ) ) ) ) {
printf ( "There is insufficient memory\n" );
return 1;
} else {
/* copy contents to contents_copy here */
}
}

int main() {
struct Hash *hash_ptr;
char *key = "A key", *contents = "Random data";

hash_add_item ( hash_ptr, key, contents );
}

/* end hash_test.c */

$ gcc -o test hash_test.c ; ./test
Creating new contents of 4 bytes
$

I want to avoid getting the caller to calculate to the size of the pointers
they're passing if at all possible.

Thanks again,
-Ian

 

[pete]

And now I get to display my ignorance .
Is there an easy way to determine
the size of the memory pointed to by a pointer?

/* begin hash_test.c */

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

int hash_add_item ( struct Hash *hash_ptr, char *key, void* contents )

int hash_add_item ( struct Hash *hash_ptr, char *key,
void* contents, size_t contents_size )

 

[LibraryUser]

And now I get to display my ignorance . Is there an easy way
to determine the size of the memory pointed to by a pointer?

/* begin hash_test.c */
.... snip ...

I want to avoid getting the caller to calculate to the size of
the pointers they're passing if at all possible.

You might want to examine the techniques used in hashlib (see:

<http://cbfalconer.home.att.net/download/> )

to handle this sort of thing. In general, only the caller can
possibly know the size of memory required to store his data, so
it should be his responsibility to allocate that memory.