Another not so interesting tale…Lots of thing you learn from mistakes and lots of knowledge you gain. When I started iphone development, I chose non-ARC way to know and learn the concepts of memory management. It was fun and good experience apart from objective-c being ugly(syntax). Whenever there was memory leak and any crash due to low on memory, it used to give me dose of excitement, debugging tits and bits had been good learning experience. It has been good journey for me. I started ARC later and life’s been good and easy for me.

I was trying to do some experiment with one iphone project based on facebook. I remember when my project was already using SBJSON for parsing json, then later when I had to integrate facebook to my project and I had lots of sbjson conflict errors. It seemed facebook was using another version of SBJSON library, so I had to remove my SBJSON and integrate the library that facebook was using. I found it in github facebook project. So that was another experience and at that time I was working on non-arc environment. So recently I tried to do something to see the result on what would happen if I do along these lines. So I created ARC based project and integrated facebook sdk 3.1 and then I integarted that same SBJSON that I had integrated on past to avoid conflict. This time my project and facebook sdk was ARC based and SBJSON was non-arc. So I decided to see the result by changing all lines of releasing memory to setting them to nil on the source codes of SBJSON. As release call will throw syntax error in arc environment so I was replacing them by nil assignment. Why nil assignment ? Well I wanted to see if there is any harm with that?

Everthing was fine. I was making rest call to my web services and parsing json. Then moment came and one crash sting me like a bee. So my crash error was this:

MyApp(2121,0xb0185000) malloc: *** error for object 0x1068310: double free
*** set a breakpoint in malloc_error_break to debug

From the description it was clear that I was trying to release already released memory. But big question was WHERE? Then as error asked me to do, I did set a breakpoint on malloc_error_break but still it was not enough for me. I need more clear error log, so I enabled zombies and trust me!! at this point of time zombies is your best friend. So as I knew I got a very clear picture, yeah NAKED CLEAR

[NSDecimalNumber retain]: message sent to deallocated instance

So it seems my decimal number has already been released before retain was called. Now another big question was NSDecimalNumber ????

I decided to play with parsing json because this crash was coming only parsing certain type of value. So I need to dig up more deeper. I was parsing every kind of value and trying to replicate the crash. Then crash happened and I had a big stupid grin on my face. I again tested parsing same kind of data and crash happened again and my stupid grin went wider. So crash was happening when I was parsing numbers. Something like this {“answer”:5} Now time was to follow the trails. So I started from [responseString JSONValue] , responseString is string and JSONValue is a method added via category. So I opened NSSting+SBJSON.m file and looked for the function. Now within function SBJsonParser was being used to parse the string, so I opened SBJsonParser.m file and searched for NSDecimalNumber because my best friend zombie told me I had a memory boom with decimal numbers. I got goosebumps when I found the stupid but very critical mistake I had made and it was the culprit of existence of this post that you are reading now. 😀 So my mistake happend on this method

(BOOL)scanNumber:(NSNumber **)o

See this is why I love zombie as it told me the problem was with decimalnumber and see where did I end up with. Yeah scanNumber! 😛 Now time for showing my mistake, but I would also like you to check the source code and look by yourself and I guess you already have SBJSON library.

@autoreleasepool {
    id str = [[NSString alloc] initWithBytesNoCopy:(char*)ns
                                            length:c - ns
                                          encoding:NSUTF8StringEncoding
                                      freeWhenDone:NO];

    if (str && (*o = [NSDecimalNumber decimalNumberWithString:str]))
        return YES;
}

and original lines of code was like this:

id str = [[NSString alloc] initWithBytesNoCopy:(char*)ns
                                            length:c - ns
                                          encoding:NSUTF8StringEncoding
                                      freeWhenDone:NO];
[str autorelease];
if (str && (*o = [NSDecimalNumber decimalNumberWithString:str]))
    return YES;

My mistake was that I used @autoreleasepool block because in hurry I couldn’t see that in original source code NSAutoreleasePool was not used and when I was using @autoreleasepool then all the autoreleased object was getting released after finish of the block. In my case decimalNumberWithString got released after releasepool block was finished and YES carriage was return. So later *o was pointing to deallocated memory and my app was crashing whenever I was parsing numbers.

But this was worth it and lots of fun debugging this crash. Also I am posting screenshot of enabling zombie objects