4

I am using ARC in my application with core data and threading etc, after doing all that hard work to get core data work with threading without any crashes now I am getting a new crash with the reason-

double free*** set a breakpoint in malloc_error_break to debug

How am I supposed to handle this? I have no control on the objects' retain counts.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
Yogesh Maheshwari
  • 1,324
  • 2
  • 16
  • 37
  • This has nothing to do with the objects' retain counts. This message is one of glibc's built-in error messages. This particular one points out that you've explicitly used free() on the same memory area twice. –  May 14 '12 at 16:25
  • No I haven't done anything like free() or malloc(). – Yogesh Maheshwari May 14 '12 at 16:29
  • Then could you please provide a little more debugging information? Like some more error messages, maybe youl should compile with -g and do a backtrace in gdb etc. else we can't really help... –  May 14 '12 at 16:31
  • Where is your app stoping when you set the recommended breakpoint? That is a good area of the code to examine more closely. – Mark May 14 '12 at 20:02
  • @H2CO3 How do I get the backtrace as you were saying.. – Yogesh Maheshwari May 16 '12 at 05:51
  • Compile the code with -g, then run it in gdb, then when it stops, type `backtrace` –  May 16 '12 at 12:40
  • I got a similar error when I forgot to mark a destructor `virtual` in a base class I was inheriting from (C++ segment of code). – bobobobo Apr 29 '13 at 23:56

2 Answers2

8
  1. Enable Zombie
  2. Follow this link : http://iphone2020.wordpress.com/2012/02/23/capturing-exceptions-while-debugging/. This will suggest exact point of crash.
Naveen Thunga
  • 3,675
  • 2
  • 24
  • 31
  • Use it only for testing purpose. While giving build remove the reference!! – Naveen Thunga Oct 16 '12 at 07:13
  • That link seems to be down (never loads). Can you maybe give some insight as to what needs to be done. I have used Zombies in the past but not that extensively. @NaveenThunga (thanks!) – owen gerig Feb 20 '13 at 17:23
1

If you want to know who destroyed the allocation:

Simply breaking as the message suggests will give you clues.

If you want to know who created the allocation:

Although you can also do this from the command line using malloc stack logging, it may be a gentler introduction to use Instruments. Run the program with allocation recording enabled in instruments, reproduce the issue, then look up the address in instruments of the double free -- it will show you the backtrace of the allocation's creation. then figure why that allocation was freed twice.

justin
  • 104,054
  • 14
  • 179
  • 226
  • Could you share the steps for adding the breakpoint for malloc_error_break? – Kudit Feb 25 '13 at 03:43
  • @Gujamin i suspect you did not search first -- i entered `malloc_error_break` into stack overflow. the first result answers your question (step-by-step): http://stackoverflow.com/questions/6923853/how-to-set-malloc-error-break-in-xcode4 – justin Feb 25 '13 at 06:48
  • I had followed those steps (adding the `malloc_error_break` symbolic breakpoint) but it didn't stop anywhere in my code and again reported `*** error: can't allocate region *** set a breakpoint in malloc_error_break to debug` – Kudit Mar 26 '13 at 17:25