Goldenseal Pro- Memory Sleuthing (Aug 24)

Last week’s switch to ARC (Automatic Reference Counting) seemed to go without a hitch. Our staff was cruising along, finishing up the Preferences window and a few other details. Then, we went to edit a list on Wednesday, and the app crashed. It never did that before.  Xcode usually shows a ‘stack trace’ that explains what went wrong, but this one only had the program entry point. That’s a very hard crash.

A while back I mentioned that the completion date for Goldenseal Pro depends mostly on how many curve balls the Cocoa framework throws at us. Each is different, but here is how we are handling this particular problem.

When there are no clues, the first thing we do is to step through the code to see exactly where it goes wrong. The process can be tedious, but usually it ferrets out an obvious error. This one turned out to be tougher. Sometimes the window would crash immediately. Sometimes it would open and stick around for a few seconds, then crash. Sometimes it would wait until we clicked something. There was no smoking gun in the code.

That delay made it seem like it might be caused by ARC deleting something prematurely. Sure enough, turning off ARC made it work OK again.

Apple has several diagnostic tools that can help with memory errors, including something called NSZombie. We tried them, and discovered that the window itself was being deleted too soon. Very odd. Nothing in the code should have done that. We stepped through the code many times, but didn’t find a smoking gun.

98% of the time, when something doesn’t work we can figure out why, and make a fix that makes sense. Then there is the other 2%, where our staff is totally baffled, and has no idea what’s going on. This is one of those.

One approach that sometimes helps is to go back to older versions and see if they also break. Finding the date when things go bad really narrows down the possible culprits. Unfortunately, older copies also work fine without ARC, but break with it.

Next step was to start deleting things from the window. That usually narrows the problem down to one specific control. Except it didn’t. The app crashed, even with everything removed.  Very odd. Along the way, there was an error warning for a button that was deleted last year. Also odd. A search in the code didn’t turn up any mention of it, but Xcode thought it was still there. That suggests some sort of file corruption in Xcode’s layout data. Why it would only break under ARC, we have no idea.

The list window was the very first Cocoa we worked on, almost two years ago. We made many mistakes and changes, so it is the most likely file to be corrupted. The solution is to just build it again from scratch. That’s on the agenda for today. We will add a few things at a time and test it frequently.

In general, the goal is to have very few changes made between working and failing versions. Then it’s easier to see what’s wrong.

Meanwhile, if we turn off ARC, lists work fine. If we turn it on, everything else still works fine. So we added some code to make it easy to switch ARC on and off. Now it just requires one line of code, instead of 100 changes. That way we can proceed productively, despite this curve ball.

If the rebuild doesn’t fix it, this may be the kind of problem where it’s best to just give up for a while. Sometimes an answer appears out of the blue, weeks or months later. Or, sometimes we accidentally fix it when we fix something else.

To be continued…

Dennis Kolva
Programming Director


Author: Dennis Kolva

Programming Director for Turtle Creek Software. Design & planning of accounting and estimating software.