Sunday, July 5, 2009

Crash Log Symbols

A few days ago my application got rejected from AppStore :(

What they sent me was a crash log. It had a bad access exception and stack traces of a couple of threads. But the poor thing about all this was that there were no symbols in the stack traces. There were only addresses of the methods :S

I google'd this problem alot and found that there is a script named symbolicatecrash at this path:


If you have the .dSYM and .app file of the build you sent to Apple, you can use these two files two generate the symbols in the crashlogs.

Fortunately I had those files and I used that script but the result was that only iPhone classes were symbolicated.

I google'd the problem again and found that there is something wrong with the script. By some searching on the internet i was able to find the correct script. Its in perl language.

using that script i was successfully able to generate symbols of the crash logs.

You can do it like this (Assume your application name is pingpong):

1. Copy the .dSYM , .app , the perl script in any folder.
2. open terminal and go to that folder.
3. Execute command:

perl pingpong.crash pingpong.dSYM > sym_pingpong.crash

After the successful execution of this command your symbolicated crash log will be sym_pingpong.crash

You can get the script from this link:


Sunday, June 14, 2009

How to write your Operating System


I was just thinking of sharing my experience of Operating System implementation. So here it is. here i will tell you the steps to implement your Operating System from scratch.

It will be a small kernel implementation. It will boot and you can run small programs on it. This kernel will run on intel x86 machine.


. DJGPP compiler.
. Virtual machine, I will use Bochs.


we will start from a main function. This function will be called when our operating system starts.
In this function you will disable interrupts.
In this function you will initialize the PIC to make first IRQ aligned with int 30 so that it does not mix up with int 1,2 and onwards.

now you are setup. you can check and execute any helloworld programs here.

you are ready to move to the next steps.

Memory Initialization:

When you boot using the grub loader you will be given the start and end address of your kernel.
Now here you have to implement the memory management. first you have to mark all the memory frames as not used. you will use 1 bit per each frame. Allocate byte array equal to:

size = memory /(4096*8)

where 4096 is page size.

This is your frame state array. initialize it with 0 which means all your memory is free. Now mark the frames that fall in your kernel start and end address equal to one to keep record that these frames are already used.

to be continued..

Wednesday, June 10, 2009

UIViewController ViewDidLoad

I just wanted to share my experience with UIViewController ViewDidLoad method in iPhone SDK.

Most of the people including me(used to) think that the UIViewController ViewDidLoad method is called only once when the Controller object is created and added in the Super View (or given a tag etc). But what i experienced that this method might get called multiple times. Sorry to disappoint you.

When ViewDidLoad method of your UIViewController is called, it renders your view and saves a copy of it in iPhone cache. This cached view is not removed from cache even you remove your view from the super view. So when you display this view again, it does not call ViewDidLoad of your UIViewController.

As you know that there is didReceiveMemoryWarning method in a UIViewController. When the iPhone gets low in memory it calls this function of the view that is having largest amount of memory. And if you have called the same function of the super class like this:

[super didReceiveMemoryWarning];

then your rendered view will be removed from the iPhone cache.
So before your view will appear on the iPhone screen next time, its ViewDidLoad will be called again to render it.

So you should avoid doing all your initialization and important stuff in the ViewDidLoad otherwise you will have problems in the above mentioned scenario.

I hope this post helps you during your iPhone development.

Sunday, June 7, 2009

iPhone Application Memory Management Tips


This part of my blog is dedicated to the memory management tips for iPhone application development. In this article I have tried to explain the things I have learnt during my iPhone application development. Any update or comment is highly appreciated.

First of all we start with the simple and most common question,

How much memory an iPhone application can allocate?

There is no exact answer to this question because the memory an iPhone application can allocate entirely depend on the current memory state of the iPhone. The most common scenarios are as follows:

  • If you have just restarted your iPhone i.e. it’s a fresh reboot then you will be able to allocate approximately 35-40 MB before you receive the memory warning.
  • Installing an application in your iPhone through Xcode is a big task and it takes a lot of memory. So after installing the application on the device It is more likely to happen that you will not be able to allocate memory more then 20-25 MB.
  • The amount of memory you can allocate also depends on the background processes currently running. And if there are memory leaks or extensive object allocation in those processes then your application will not be able to get much memory.

So the lesson we have learnt so far from the previous question is that we have to build our application with as much memory optimization as we can. To do this you can follow the following tips.


By resources I mean the images, Nibs, Web pages and sounds etc. As you load a resource in your iPhone application, iPhone caches that resource in the memory so that next time it loads quickly. So if you have big resource files and you are loading them frequently then what happens is that these pile up in the memory and become the reason of your application crash.

· Avoid use of imageNamed: For images we mostly use the imageNamed: message to load the image. I agree that its very easy to use but what when you load your image using the imageNamed: message, the iPhone caches that image into the memory. So you should only use this message in specific scenarios when you really need image caching, Otherwise you can use the following method to load the image.

-(UIImage *) myImageLoader:(NSString *) filename


NSString *imageFile = [[NSString alloc] initWithFormat:@"%@/%@",

[[NSBundle mainBundle] resourcePath], filename];

UIImage *image = nil;

image = [[[UIImage alloc] initWithContentsOfFile:imageFile] autorelease];

[imageFile release];

return image;


You can use this method in the same way you use ImageNamed:

· Nibs: When you create a view using the interface builder and load that nib using a UIViewController sub class, all the objects in that view are loaded and all the resources associated to that view are loaded. When you add this view to superView, the retain count of this view is incremented. And when this view is removed from its superView then this view is released and all the objects in it are also released.

When you bind an object in your code with the object in the Nib (using IBOutlet), then it becomes your responsibility to make sure that the object you have binded is released when your view is released. To do this:

1. If you have not defined this IBOutlet as property and have not synthesized it then you have to release this object in the dealloc of your ViewController. Otherwise this object will remain in the memory when your view is removed from the superview.

2. If you have defined this IBOutlet as a property using assign then you have to synthesize it also. Now this object will be automatically released when your view is removed from superview.

3. If you have defined this IBOutlet as a property using retain then you have to synthesize it also and release it in dealloc of your ViewController. Now this object will be released when your view is removed from superview.

Static Messages:

In iphone SDK you find static methods with some classes to create an instance of that class. For Example:

[NSString stringWithString:@”Hello Sami”]

[UIImage imageNamed:@”tom.png”]

When you create an object using these static messages, The object is added in the autorelease pool that is created in the main() function of your application. Using these static functions to create the objects is not reliable because most of the objects remain in that autorelease pool until your application terminates.

I hope you find this post interesting and of use. I will post more information on this topic soon.