Best way to test and find crashes

[bytor99999]

I have bugs in my application that I would love to fix. But the problem is I can't always replicate it with the same conditions. And right now, I can't make it break at all. It seems to break when I am showing it off to someone else.

I don't have any crash reports on it to even help me out.

So what is the best approach to testing, different devices and finding some deep root causes of bugs.

Thanks

Mark

[Duncan C]

Originally Posted by bytor99999

I have bugs in my application that I would love to fix. But the problem is I can't always replicate it with the same conditions. And right now, I can't make it break at all. It seems to break when I am showing it off to someone else.

I don't have any crash reports on it to even help me out.

So what is the best approach to testing, different devices and finding some deep root causes of bugs.

Thanks

Mark

Intermittent bugs can be really hard to find. First step is to create a build where you have the source code unchanged, plus the exact executable and symbol file you are testing with. save the executable and symbol file in a second folder. The system uses the date stamp on the build to match the program and the symbol file to "symbolicate" log files, so you need to make sure you save the exact .app and symbol file that you test with. Rebuilding t without making any source changes will proven the system from matching the executable with the symbol file.

To fix this problem, you can give out a development build with symbols included. Just put your tester's UDIDs into the development profile. Give that out to testers, and teach them how to get crash logs from their devices and mail them to you. Also test the snot out of it yourself, trying to get it to crash. Sometimes the crash log shows the line that's the source of the bug.

Next, do a build and analyze on the program, and look through and fix every single problem it identifies with your code. Some, like unused variables, won't cause any harm, but it can be easy to miss a real problem if you have a ton of other issues flagged as well. Getting a build and analyze to run with no issues raised is a very good thing.

Also try running with the zombies tool in Instruments. That can find memory problems with over-released objects.

If it only crashes when you are demonstrating it, demonstrate it to people with a video camera recording the screen. Capture as many crashes as you can, and then go back and try to figure out what aspects they have in common. Frequently other people do things with your app that you don't. Programmers tend to get into a narrow path through their programs, without even realizing it. Users will do things we don't expect. That might be the reason you crash doing demos.

That's just some off-the-cuff advice. Good luck, and stick with it. Debugging takes patience and determination.

[baja_yu]

What Duncan said in the second to last paragraph is exactly why developers generally don't (and shouldn't) test software as well.

[MarkHolbrook]

I will add to this by saying that the behavior you describe sounds very much like memory issues.

I have a player app that has been running just fine for months. Never a crash. I added one line of code that allocated and assigned a data class:

playingSong = [[MJSongDataClass alloc] init];

This "playingSong" var was an instance var in a class. A while later something would try to access playingSong and the app would crash. I spent a while looking into it and surprisingly the thing that fixed it was a simple:

playingSong = [[[MJSongDataClass alloc] init] retain];

For reasons I cannot fully explain the allocated class would get autoreleased. Things like this can drive you crazy. Anyway your behavior sounds similar.

Spend the time to check and double check your memory handling.

[baja_yu]

That doesn't seem right. allocation returns a retained object, so you're double retaining it and possibly creating a leak. Your problem is that you are over-releasing it somewhere.

Also, it's best to use properties to help manage memory for pointer type instance variables.

[MarkHolbrook]

Originally Posted by baja_yu

That doesn't seem right. allocation returns a retained object, so you're double retaining it and possibly creating a leak. Your problem is that you are over-releasing it somewhere.

Also, it's best to use properties to help manage memory for pointer type instance variables.

I completely agree however I traced this object in extreme detail and and there was no release or dealloc being done. It just disappears. I've even had two other people look it over and they agreed... very strange.

[dany_dev]

you can use a similar tool

plcrashreporter - In-process CrashReporter framework for the iPhone and Mac OS X - Google Project Hosting
https://github.com/guicocoa/hoptoad-ios
https://github.com/kaler/CrashKit

[bytor99999]

Thanks guys, sorry it took me a long time to come back to this post, I was on vacation. I might have gotten a number of leaks with analyze and hope one of them that I fixed was the cause of their crashes.


I have been a developer for over 20 years with lots of debugging experience. iPhone development is not like any other language I have used. The whole finding a memory leak or crash like this is almost like looking for a needle in a haystack, and I get really confused by what Duncan posted about builds and symbols on and the creation of the ap file. I know it is probably just like creating a jar file in Java or turning on JPDA remote debugging in Java, or other language compiled artifacts, but I definitely, have to get used to the iOS way.

I also had to laugh about Duncan saying I give it to my testers. What testers? In my iOS development stuff it is just me, no one else.

Thanks

Mark