Valgrind memory leak during realloc

Question

I am not sure why Valgrind is reporting memory leak on it?

Pseudocode in .c file:

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

 char* str_alloc(char *str) {
   char* dup = (char*) malloc((strlen(str) + 1) * sizeof(char));
   strcpy((char*) dup, (char*) str);
   return dup;
 }

 void function_c(char **name) {
   int len = 10;
   (void) realloc(*name, 100);
 }

 void function_b(char **name) {
   (void) function_c(name);
 }

 void function_a(char **name) {
   (void) function_b(name);
 }

 int main() {
   char* name = str_alloc("");
   function_a(&name);
   // Do something with name
   free(name);
 }

I am ignoring the value of realloc since I am kind of sure that realloc will always be on same pointer. Allocating/Reallocating from my own memory pool which is quite huge.

Of course, I can not write the code for memory pool here.

So, In what cases shall I expect to come as Valgrind leak? Couple of cases which I thought of:

If realloc happens to smaller memory. realloc is guaranteed to take care of it.
If realloc fails, then it is supposed to be memory leak. I understand this.

Any other cases?

The code you show will not even build. When creating a [Minimal, Complete, and Verifiable Example](http://stackoverflow.com/help/mcve), make sure it's both complete and verifiable. — Some programmer dude, Sep 24 '18 at 12:46
And you should *really* read more about [`realloc`](http://en.cppreference.com/w/c/memory/realloc), and what it *returns*. It's not guaranteed that it can reallocate in place. — Some programmer dude, Sep 24 '18 at 12:47
By the way, are you asking about a *hypothetical* memory leak? Or do you have an *actual* memory leak? If the latter, then the [Minimal, Complete, and Verifiable Example](http://stackoverflow.com/help/mcve) should of the *failing* program, and should also include the Valgrind output, as well as the code containing comments indicating the lines pointed out in the Valgrind log. — Some programmer dude, Sep 24 '18 at 12:50
@Someprogrammerdude, Updated compiled version of the problem.. — Hemant Bhargava, Sep 24 '18 at 13:08
@Someprogrammerdude Updated question. Hope it clarifies your doubts now. — Hemant Bhargava, Sep 24 '18 at 14:45
@AnttiHaapala I think this is not exactly a duplicate because OP is asking about the case where they wrote the malloc implementation themselves, why can't they rely on additional guarantees it provides? — zwol, Sep 24 '18 at 14:57
Ah, you cannot implement your own `realloc` function by the name `realloc` unless you're using a freestanding implementation. — Antti Haapala -- Слава Україні, Sep 24 '18 at 15:13
And considering that you *can* use valgrind, this is not the case then — Antti Haapala -- Слава Україні, Sep 24 '18 at 15:16
@AnttiHaapala of course, you can not. That is why I wrote Pseudo code. — Hemant Bhargava, Sep 24 '18 at 15:36
@AnttiHaapala Btw, this was not a duplicate. You may want to remove that tag. — Hemant Bhargava, Sep 25 '18 at 02:29

kiran Biradar · Answer 1 · 2018-09-24T13:58:17.303

3

There is memory leak because you are loosing the memory allocated by realloc.

Syntax for realloc goes as below.

void *realloc(void *ptr, size_t size);

Note: It is not guaranteed that pointer returned by the realloc will be same as old pointer passed to realloc and one should not depend on it.

Even compiler is also warning you about the same.

warning: ignoring return value of ‘realloc’, declared with attribute warn_unused_result [-Wunused-result]
(void) realloc(*name, 100);
^

Hence you need to modify your function_c function as below.

 void function_c(char **name) 
 {
     char *newPtr = NULL;
     newPtr  =  realloc(*name, 100);
     *name = newPtr;
 }

edited Sep 24 '18 at 13:58

answered Sep 24 '18 at 13:16

kiran Biradar

12,700
3
19
44

Thanks. I agree that I am ignoring the return value of realloc. In my case, since I allocate/reallocate memory from the pool, I am.kind of sure that it will be same pointer. How about in that case? – Hemant Bhargava Sep 24 '18 at 14:35
Please checkout the answer by @zwol. – kiran Biradar Sep 24 '18 at 15:00

zwol · Accepted Answer · 2018-09-25T12:22:46.837

I am ignoring the value of realloc since I am kind of sure that realloc will always be on same pointer. Allocating/Reallocating from my own memory pool which is quite huge.

In code that uses the standard malloc/realloc/free interface, you simply cannot make this assumption, even if you think you provided the implementation and you know how it will behave under controlled conditions. Future people working on your code (including yourself, years from now after you've forgotten the details of this project) will assume there's nothing special about how your code uses standard interfaces and they can move the code onto an entirely different C implementation without bringing your special malloc library along.

Also, the C library is entitled to refuse to let you replace these functions, which is what's causing your immediate problem: valgrind forcibly substitutes its own implementation of malloc/realloc/free for whatever you had, an implementation that never returns the same pointer from realloc. This is on purpose, to catch bugs like this one.

If you want to implement a memory pool that makes guarantees such as "resizing an allocation does not move the allocation", then you need to give all of the functions new names (e.g. pool_alloc, pool_resize, pool_free).

Thanks. Valgrind comment make sense to me and clear up my doubts about the same. I do have my own implementations of malloc, calloc and realloc. — Hemant Bhargava, Sep 24 '18 at 15:03
@HemantBhargava "valgrind forcibly substitutes its own implementation" is just an example of what might go wrong. The important sentence in this answer is the first one: "In code that uses the standard malloc/realloc/free interface, you simply cannot make this assumption." It does not need extra emphasis, because it is already the first sentence. — zwol, Sep 25 '18 at 13:16

Valgrind memory leak during realloc

2 Answers2