Re: Strange crash with multithreading and -[NSUserDefaults synchronize]
Re: Strange crash with multithreading and -[NSUserDefaults synchronize]
- Subject: Re: Strange crash with multithreading and -[NSUserDefaults synchronize]
- From: Martin Redington <email@hidden>
- Date: Mon, 13 Nov 2006 03:29:35 +0000
Hi Bill
On 12 Nov 2006, at 21:51, Bill Bumgarner wrote:
NSUserDefaults is documented as thread safe. If it isn't, it is a
bug. All things considered it is unlikely that NSUserDefaults has
such a bug that prevents thread safety in such a normal usage pattern.
I agree. Hence my disbelief that NSUserDefaults access could be
causing this. Yet removing the call stops the problem.
If anyone has seen something like this before, or has any tips on
working out, from the debugger, what object its trying to access,
that would be wonderful.
-synchronize causes the user defaults object to likely walk all of
the user default's data in your app. As such, if you are over-
releasing some object passed into the user defaults, it is likely
that -synchronize might trip over it.
Our first suspicion, when we saw the more variable stack traces, was
that we were seeing an over-released object being autoreleased. Once
we tightened up the multi-threading (which was required for reasons
unrelated to NSUserDefault's thread safety), the crashes changed to
the consistent stack trace I'm seeing right now.
So, check your retain/release usage. Try running with NSZombies.
NSZombie and CFZombieLevel showed up nothing. I'm not saying its not
a retain/release issue, but it doesn't seem right to me - that should
hit us whenever NSUserDefaults is synchronized - not just in the
multi-threading case.
Back to the debugger to try and work out *what* its trying to access,
I guess ...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden