A shot in the dark - Application bug

Question

Ok so this is gonna be a bit of a shot in the dark without you being able to see my application!

I have a bug. I have a SwimmingPool class, my app passes the pool from a tableview into a detail view where you can see all the swimmingPool class fields. You can then click on the individual detail, edit it, and then save it. The 'original' pool facility is copied and passed to the view controller responsible for actually making changes. If the user presses save, the fields are copied from the copy into 'original'

switch (self.sectionFromParentTable) {
 case KNameIndex:
  self.thePoolFacility.name = self.thePoolFacilityCopy.name;
  self.thePoolFacility.type = self.thePoolFacilityCopy.type;
  break;

 case KAddressIndex:
  self.thePoolFacility.address = self.thePoolFacilityCopy.address;
  break;

 case KPhoneNumberIndex:
  self.thePoolFacility.phoneNumber = self.thePoolFacilityCopy.phoneNumber;
  break;

 case KWebAddressIndex:
  self.thePoolFacility.webAddress = self.thePoolFacilityCopy.webAddress;   
  break;
 case KPricesIndex:
  self.thePoolFacility.prices = self.thePoolFacilityCopy.prices;
  break;
 case KPoolIndex:
  self.thePoolFacility.pools = self.thePoolFacilityCopy.pools;
 default:
  break;
}

[self.navigationController popViewControllerAnimated:YES];

Can I have some guesses at a bug that does the following:

1. The bug results in the changes done to a class' fields not being saved. In particular a class called TimeEntry, in a mutable array called Monday in a Dictionary called TermTimes in a class called pool and then in a mutable array called Pools.

2. It's appears random. Sometimes it works perfectly. Sometimes it doesn't! I can't recreate the error, only if I'm lucky can i get it not to save. My hunch is it could be time sensitive. For example, If I am entering a timetable for Pool opening times, if i quickly add a few entries and save it usually works fine. If I fill in a whole timetable then it more than not doesn't save.

3. The app doesn't crash.

It's infuriating the try and debug an error that seems to happen at random. Any hints on such an epic bug hunt?

Answer 1

"random" and "hard to reproduce" makes me think that this is an issue having to do with multi-threading. Race conditions are very hard to reproduce and debug. You'll need to make sure that you have exclusive rights to the resources you need to perform this operation.

Answer 2

One of the best ways to tackle this type of problem (where it seemingly can't be reproduced reliably) is to insert logging code in various areas where you expect certain things to be happening. Log places that errors could occur, log what values you are expecting and what you have, etc. Next, try, try, try until you can reproduce the bug.

Unlike before, you now have a log to look at and see where things went wrong. If things still look correct everywhere, insert some more logging code elsewhere. If you see something go wrong, but don't understand it, put more logging code in that area and keep narrowing the problem down.

Hopefully this will lead to new hypotheses about how the bug happens, and you will be able to reproduce it under the debugger reliably and fix it!

As duffymo mentioned, multithreading could be the culprit, and would be a good place to investigate first if you're knowingly using multiple threads.

Answer 3

My suggestion is to look for nils. Any method call on a nil object simply does nothing and returns nil, so any time you're expecting a method to be called and it isn't, you should look for that. (.foo = is the same as setFoo:, so nil.foo = 1; will do nothing.)

Answer 4

Thanks for all your answers. It's now fixed.

For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.

cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.

Again it's a memory problem. Isn't this always the case!?!

The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.