1

As you know, after we finish using dynamic variables we free() them.

However, sometimes those variables are already free()d.

I need to check if it is free to avoid double free. Would anyone give me a clue?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
محمد جعفر نعمة
  • 1,045
  • 1
  • 11
  • 33
  • 2
    The interruption function must not attempt to free it under any conditions. If you take this as an axiom, you will be forced to make other changes to your design. Those changes are likely the necessary ones, not this one. – Brian Cain Jan 20 '15 at 21:19
  • 1
    see also [XY Problem](http://meta.stackexchange.com/a/66378/173950) – Brian Cain Jan 20 '15 at 21:20
  • 4
    If you're using C++, as your title suggests, why are you using `malloc` and `free` at all? – Fred Larson Jan 20 '15 at 21:26
  • @FredLarson: For interop, perhaps? Or because there is no `new` equivalent to `realloc`? – Deduplicator Jan 20 '15 at 21:26
  • 1
    @Mgetz: So, you pass memory not allocated with `malloc` to an interface expecting it being allocated thus, and expect things to work out fine? – Deduplicator Jan 20 '15 at 21:28
  • @Deduplicator if you're transferring ownership then the question is irrelevant – Mgetz Jan 20 '15 at 21:29
  • _"As you know, after we finish using heap variables we free() them."_ Woah woah woah not in C++ we don't!! – Lightness Races in Orbit Jan 20 '15 at 21:39
  • Also, neither "heap variable" nor "memory variable" is a good name at all for objects of dynamic storage duration. – Lightness Races in Orbit Jan 20 '15 at 21:40
  • The original text of this question discussed memory handling in a signal handler. Please read the answers to [How to avoid using `printf()` in a signal handler](http://stackoverflow.com/questions/16891019/how-to-avoid-using-printf-in-a-signal-handler). There are many restrictions on which functions you can call from a signal, some of them surprising (`strlen()` is not listed as safe, for example), and some of them less surprising (`malloc()`, `realloc()`, `free()` are not listed as safe). – Jonathan Leffler Feb 07 '15 at 05:42

2 Answers2

13

You can't check if it's already been free'd (the signature of free should tell you that much; it can't modify the pointer from the caller's perspective). However, you can do one of two things.

  1. Change your design. Who is responsible for this memory? It seems as though your design does not make that clear, which is the most common reason for memory leaks. Place ownership on one part of your code and be done with it. Why would the interrupt function conditionally deallocate the memory? Why does that seem like the most logical solution?

  2. Set the pointer to null and double free all you like. free(NULL) is perfectly valid.

I prefer option 1 and learning this lesson now will help you write better code down the road.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
4

+1 to Ed S.'s answer.

But also, run valgrind - it will pick up many dynamic memory allocation errors quickly, and may be better at reading your code than you are.

abligh
  • 24,573
  • 4
  • 47
  • 84