Ios – set a breakpoint in malloc_error_break to debug

debuggingiosmallocobjective c

For me here getting error :

[self.points addObject:@{@"latt": 
[NSNumber numberWithFloat:(latitudeString.floatValue)],@"long": [NSNumber numberWithFloat:(longitudeString.floatValue]}];

Like this: malloc: * error for object 0x7f8480743a00: pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug

After adding malloc_error_break in Symbolic Breakpoint in Breakpoint Navigator getting same error

Best Answer

For memory errors of this sort, ASAN (address sanitizer) can often be a helpful tool. It instruments your code so that it can catch incorrect uses of malloc & free where they happen, rather than later when they blow up. And it records the history of allocation & free events for a given address, so for instance if you had a double free, it would show you both free points.

You turn this on by editing the Run Scheme in Xcode, going to the Diagnostics tab, and turning on Address Sanitizer. This will require a rebuild, and the instrumented binaries will run a little slower, but generally not so much slower that you can't get your program to the point of failure.

Related Solutions

What REALLY happens when you don’t free after malloc

Just about every modern operating system will recover all the allocated memory space after a program exits. The only exception I can think of might be something like Palm OS where the program's static storage and runtime memory are pretty much the same thing, so not freeing might cause the program to take up more storage. (I'm only speculating here.)

So generally, there's no harm in it, except the runtime cost of having more storage than you need. Certainly in the example you give, you want to keep the memory for a variable that might be used until it's cleared.

However, it's considered good style to free memory as soon as you don't need it any more, and to free anything you still have around on program exit. It's more of an exercise in knowing what memory you're using, and thinking about whether you still need it. If you don't keep track, you might have memory leaks.

On the other hand, the similar admonition to close your files on exit has a much more concrete result - if you don't, the data you wrote to them might not get flushed, or if they're a temp file, they might not get deleted when you're done. Also, database handles should have their transactions committed and then closed when you're done with them. Similarly, if you're using an object oriented language like C++ or Objective C, not freeing an object when you're done with it will mean the destructor will never get called, and any resources the class is responsible might not get cleaned up.

Javascript – How to debug Node.js applications

node-inspector could save the day! Use it from any browser supporting WebSocket. Breakpoints, profiler, livecoding, etc... It is really awesome.

Install it with:

npm install -g node-inspector

Then run:

node-debug app.js

Best Answer

Related Solutions

What REALLY happens when you don’t free after malloc

Javascript – How to debug Node.js applications

Related Topic