C : freeing a reallocated pointer

Question

I found out today that when I try to free a pointer that has been reallocated the program crashes and prints "Segmentation Fault".

A realloc() is called on this pointer (array) in order to sizeup the array and merge the old array and another one.

Further in the program I must free it, how can I bypass this problem without having to make some sort of buffer array, adding the 2 other arrays to it and then to free them?

PARTICLE: structure
newCount: sum of the size of the old array + array that is being added

Code:

group1->particleList = 
         (PARTICLE *) realloc(group1->particleList, newCount * sizeof(PARTICLE));

@RageD If the fault happens on `free`, does it matter? (Of course it might happen elsewhere?) — , May 08 '12 at 20:32
`ptr=realloc(ptr,size)` is a bad habit although probably not the issue here. — Flexo, May 08 '12 at 20:33
The problem is most likely that you are (somewhere) writing beyond the end of an allocated block, causing heap corruption. It's perfectly fine to `free` memory allocated with `realloc`, so that's not the problem. — David Gelhar, May 08 '12 at 20:34
You probably have a memory-related bug in your code which only shows up later when you call free() - try running under valgrind to track it down. — Paul R, May 08 '12 at 20:34
The array is a 1D array with a structure type, so it's allocated with a simple malloc(). — DennisVDB, May 08 '12 at 20:34
@DavidGelhar - or double free, or freeing a pointer that is now dangling because of an earlier realloc — Flexo, May 08 '12 at 20:34
Just as a note, casting the result of `malloc` (and friends) is generally discouraged. — dreamlax, May 08 '12 at 20:35
@awoodland good point; dangling pointer is certainly possible given the use of realloc — David Gelhar, May 08 '12 at 20:35
@DnX - Recompile the program with debugging symbols, then run it with `valgrind`, and interpret the result. Or paste it here. It really helps with memory related bugs. — ArjunShankar, May 08 '12 at 20:36
Can you make a minimal but complete example that reproduces the problem? Otherwise we could speculate here all day! — Flexo, May 08 '12 at 20:36
Agree with @DavidGelhar, it is unlikely to be problem with `realloc` itself. If you are on Linux, try checking your program with `valgrind`: it is must-use tool for any pointer-using application, IMO. — aland, May 08 '12 at 20:37
@ArjunShankar - if realloc fails it returns `NULL`, but doesn't free the old pointer. Result: memory that nothing points to anymore. See this question: http://stackoverflow.com/q/9071566/168175 — Flexo, May 08 '12 at 20:38
@awoodland - Right, thanks. One may find it convenient to wrap `*alloc` calls in functions which check for `NULL`. — ArjunShankar, May 08 '12 at 20:54
@ArjunShankar yes - the question still remains though what to do when you get a NULL return. Returning the original pointer gives no indication the call failed. Calling `free()` on the original pointer and returning `NULL` loses data that was still perfectly OK in memory. In the end it normally boils down to hooking in to the local preferred error handling/logging mechanism directly. — Flexo, May 08 '12 at 20:56
@awoodland - I've been dabbling in gcc source recently. The developers have a nice set of wrappers, which basically do an `exit(1)` if the allocation fails (their point probably being - "You cannot continue compiling if you cannot even allocate this block of memory, so why return anything to callee? Just exit instead"): http://gcc.gnu.org/viewcvs/trunk/libiberty/xmalloc.c?view=markup — ArjunShankar, May 08 '12 at 21:06

score 2 · Answer 1 · answered May 08 '12 at 20:39

2

There should be no problem freeing a reallocated pointer. A program called valgrind can give you some valuable information about what is going on in your code.

answered May 08 '12 at 20:39

Ras

89
5

score 1 · Answer 2 · answered May 08 '12 at 20:39

Did you include "stdlib.h" ?

Casting the return of realloc and friends can hide the problem of having no prototype for it. Older compilers then take it to return an int, cast that int to a pointer type and the damage is done.

The problem that realloc would return 0 as others mention, shouldn't result in a fault when you free the buffer, but much earlier.

score 0 · Answer 3 · answered May 08 '12 at 20:37

0

First, make sure you assign the result of realloc to a temporary variable; if the request fails, realloc will return NULL, and you'll lose your handle on the memory you've already allocated:

PARTICLE *tmp = realloc(group1->particleList, ...); // cast is unnecessary
if (tmp)
  group1->particlelist = tmp;
else
  /* handle realloc failure */

Make sure you aren't accidentally overwriting group1->particleList (possibly in your merge code?) before the free call. Even if it was getting overwritten with NULL in the event of a failed realloc call, free should be able to handle a NULL argument (basically, it'd be a no-op).

answered May 08 '12 at 20:37

John Bode

119,563
19
122
198

1

This is a good advice, but it won't solve the crash in this case. – Sjoerd May 08 '12 at 20:46
It's weird but after reactivating the free of the the array the segmentation fault disappeared (or maybe was random...). I'm now pushing my program through valgrind in order to understand why I'm getting a segmentation fault that seems random, could valgrind stop a segmentation fault because I only get it when running it without valgrind. When I run it via valgrind the program doesn't crash but does some weird things in place of the segmentation fault. – DennisVDB May 09 '12 at 12:47
Without seeing more of the code, it's impossible to say for sure. You're definitely clobbering memory *somewhere*; whether that's due to an out-of-bounds array access, or from dereferencing an invalid pointer, or something else, is an open question. Valgrind's a useful tool, but it doesn't catch everything. – John Bode May 09 '12 at 14:02
I'm going to review my code entirely. It's a wild pointer paradise I suppose. – DennisVDB May 09 '12 at 19:26

C : freeing a reallocated pointer

3 Answers3