How to free ptr to this nested struct?

[Alfonso Morra]

Hi,

I've defined the ff structs:

struct _my_nested_data {
int size;
void *data;
};

typedef struct {
int check;
int size_1;
int size_2;
struct _my_nested_data *curr;
} ParentData;


In my code I correctly allocate memory to a ptr to ParentData struct,
and use the variable succesfully. However, whe I want to free this
variable (type = ParentData*), I do so using

free(variable_name) and I get a crash. Do I need to free the nested
struct first?

 

[Artie Gold]

Hi,

I've defined the ff structs:

struct _my_nested_data {
int size;
void *data;
};

typedef struct {
int check;
int size_1;
int size_2;
struct _my_nested_data *curr;
} ParentData;


In my code I correctly allocate memory to a ptr to ParentData struct,
and use the variable succesfully. However, whe I want to free this
variable (type = ParentData*), I do so using

free(variable_name) and I get a crash. Do I need to free the nested
struct first?

"That which you malloc() shalt thou free."

Yes, you do need to free the pointer to the `struct my_nested_data'
first (assuming you allocated it); once you've freed the parent you have
no way to get to the `inner' struct.

Not doing so, however, would cause a memory leak (to be avoided, of
course) but *not* a crash.

In virtually all cases, a crash in free() indicates a corrupted free
store, i.e. you've somehow overwritten a piece of the allocator's meta data.

HTH,
--ag

 

[Christopher Benson-Manica]

struct _my_nested_data {
int size;
void *data;
};

Identifiers beginning with underscores are, IIRC, reserved for the
implementation's internal use.

typedef struct {
int check;
int size_1;
int size_2;
struct _my_nested_data *curr;
} ParentData;

In my code I correctly allocate memory to a ptr to ParentData struct,
and use the variable succesfully. However, whe I want to free this
variable (type = ParentData*), I do so using
free(variable_name) and I get a crash. Do I need to free the nested
struct first?

Yes, but failure to do so results in a memory leak, not a crash. It's
possible that your program's memory space became corrupted at some
point, which will make any calls to free() susceptible to failure.

 

[Martin Ambuhl]

Alfonso Morra wrote:
[...]

Do I need to free the nested
struct first?

Yes, for the obvious reason that attempting later to use a pointer in
the no-longer-pointed-to parent structure involves a reference using a
no longer meaningful pointer.

 

[Michael Mair]

Identifiers beginning with underscores are, IIRC, reserved for the
implementation's internal use.

This concerns identifiers beginning with _ followed by _ or A-Z;
identifiers beginning with _ are, in principle, allowed but only
as file scope identifiers, not as external identifiers.

Cheers
Michael

 

[Christopher Benson-Manica]

This concerns identifiers beginning with _ followed by _ or A-Z;
identifiers beginning with _ are, in principle, allowed but only
as file scope identifiers, not as external identifiers.

So IOW, OP's declaration

is missing the word "static" but is otherwise conforming?

 

[Emmanuel Delahaye]

Artie Gold wrote on 19/09/05 :

Yes, you do need to free the pointer

There was no allocated pointer to be freed. There was an allocated
memory bloc and a pointer holding the address of the block.

What is to be freed is the memory bloc itself, not the pointer.

This common vocabulary mistake is misleading, specially for beginners
having hard time with pointers...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Keith Thompson]

Artie Gold wrote on 19/09/05 :

There was no allocated pointer to be freed. There was an allocated
memory bloc and a pointer holding the address of the block.

What is to be freed is the memory bloc itself, not the pointer.

And the way to free the memory bloc is to pass the pointer value to
free().

This common vocabulary mistake is misleading, specially for beginners
having hard time with pointers...

Agreed.

 

[Alfonso Morra]

Hi,

I've defined the ff structs:

struct _my_nested_data {
int size;
void *data;
};

typedef struct {
int check;
int size_1;
int size_2;
struct _my_nested_data *curr;
} ParentData;


In my code I correctly allocate memory to a ptr to ParentData struct,
and use the variable succesfully. However, whe I want to free this
variable (type = ParentData*), I do so using

free(variable_name) and I get a crash. Do I need to free the nested
struct first?

A bit of a red herring this one - the crash was being caused because I
was doing the malloc in a shared lib (actually DLL), but then calling
free() in the process that loaded the DLL. Silly really if you thing
about it - too different adress spaces. I dont know what I was thinking
.... sorry guys.

 

[Jack Klein]

This concerns identifiers beginning with _ followed by _ or A-Z;
identifiers beginning with _ are, in principle, allowed but only
as file scope identifiers, not as external identifiers.

Sorry, but you're wrong on this one. Here's the wording from the
standard, 7.1.3 P1 second item in the list:

"All identifiers that begin with an underscore are always reserved for
use as identifiers with file scope in both the ordinary and tag name
spaces."

So you can never begin an identifier with an underscore at all, even
if its entire spelling is "_", at file scope if you want to stay
legal, regardless of linkage.

 

[Artie Gold]

Artie Gold wrote on 19/09/05 :



There was no allocated pointer to be freed. There was an allocated
memory bloc and a pointer holding the address of the block.

What is to be freed is the memory bloc itself, not the pointer.

This common vocabulary mistake is misleading, specially for beginners
having hard time with pointers...

Indeed. Perhaps I should have said, "You need to free() the pointer," or
somesuch.

Cheers,
--ag

[Be nice to me. I remember when you were a rotund, less than intelligent
cartoon character with an affinity for doughnuts and Duff's (the
animated beer, not the device) ;-) ;-)]

 

[Artie Gold]

A bit of a red herring this one - the crash was being caused because I
was doing the malloc in a shared lib (actually DLL), but then calling
free() in the process that loaded the DLL. Silly really if you thing
about it - too different adress spaces. I dont know what I was thinking
... sorry guys.

Ya gotta love non-standard, erm, `extensions' provided by certain platforms.

Well, actually, ya don't.

Cheers,
--ag