views:

27

answers:

2

Further to this question: http://stackoverflow.com/questions/3576724/nsrunloop-is-receiving-a-strange-selector-possible-race-condition-tomfoolery - where it was discovered that a UIGestureRecognizer was being deallocated and then receiving a message, I printed out the address of one of my GRs in order to see if it was the one being reported by zombies.

With the print message in the code, I can no longer cause the crash I was originally looking for. Removing the print message, it seems I can cause it again.

Since we're dealing with a deallocation/retain/release problem, can anyone tell me if it's possible that printing out this object is causing it to be referenced, thus sparing it from deallocation? And if so, what does that tell me about my original problem? Too many release's? Release too early?

+1  A: 

In 10 years of Mac and iOS development, it never happened to me that NSLog did something bad to reference counts. That's all I can say for sure.

Max Seelemann
+1  A: 

If the call to NSLog is from a background thread, then that could well be changing the sequence of events. NSLog synchronizes writes to stderr in some way -- I am not sure exactly how, but it's not far-fetched to think that one consequence could be an alteration in your object's lifetime.

As to what that tells you about the original problem, well it sounds like it confirms Dave DeLong's diagnosis: you're attempting to use a stale pointer. Which in turn means either the bit of code making the call is not retaining appropriately, or some other bit is over-releasing.

walkytalky
I've fixed it by not reallocating the gesture-recogniser each time. It wasn't a great idea anyway, and it turns out that the object receiving a message post-deallocation was an old gesture recogniser I'd released. So I don't know how it was happening, but it's obvious that it wasn't a good thing. All sorted, thanks all!
mtc06