Serious problem with NSUserDefaults? stringForKey: returning nil, value is in user defaults

UI Frameworks AppKit
Macho Man Randy Savage OP
Created Oct ’17
Replies 23
Boosts 0
Views 13k
Participants 7

This is weird, and I hope it only is occurring in debug mode. But I have a string saved in user defaults. And I'm noticing every so often user defaults is returning nil. And it is making my app act weird. I just caught the problem like this:


-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender
{
     NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
     NSString *code = [userDefaults stringForKey:KEY_HERE];

     if (code == nil)
    {
       return YES;
     }
    return NO;
}


Now....I close the last window several times, and the string does get returned. But I noticed after awhile, stringForKey: returns nil out of nowhere and my app terminates. Then on next launch, stringForKey: returns the actual value again (not nil). Is there a known cause for this?

Replies  23
Boosts  0
Views  13k
Participants  7
elemans OP
Nov ’17

No any improvements detected in 10.13.1 regarding NSUserDefaults

0
Macho Man Randy Savage OP
Nov ’17

I saw that Open Radar a few days ago too. In my app I do not use restorable windows. Don't know what causes it, since we don't have the source. Sometimes window resizing, or opening / closing a window seems to trigger it. Maybe just coincidental though. It's as if somewhere someone put in a performSelector:afterDelay and decided to blow up the world after a little delay.


Hard for me to understand why this wouldn't be considered a high priority issue, considering the fact that practically every app uses NSUserDefaults. Can't put it on the Mac App Store, but if someone can track down the private method that's blowing us up, perhaps we can swizzle it.

0
Jan OP
Nov ’17

I just wanted to add my observations …


I definitely witnessed a comparable issue on Sierra already: about once every other day or so, my App had a weird issue that could only really be explained by NSUserDefaults returning nil (or perhaps the default value?).


And I was able to verify comparable cases (like above) where I was sure to set a value, got back nil on next use, but after a restart the value was correct again.

Once or twice I saw something like this in the log when it happened: "Detected potentially harmful notification post rate of 266.189 notifications per second".


In addition to that issue, on High Sierra I now frequently get this, too (mentioned elsewere already): https://openradar.appspot.com/34759647

where intermittently the app forgets all (or at least many) default-values until a restart. I saw it seemingly related to NSOpenPanel, too, but I am almost 100% certain that it was not limited to using these panels here. (I even saw something like this with Xcode once: many editor settings were suddenly gone, and a restart fixed that.)


This second issue is so bad here now that I planned to do a fresh system install this week, because I thought this HAS to be a "broken system" issue … Hm, not sure what to do now.

0
elemans OP
Nov ’17

Some more developers on Twitter with NSUserDefaults issues in macOS 10.13 (and 10.12.6)

https://twitter.com/daniel_a_a/status/918026469674242048

0
elemans OP
Dec ’17

David Smith (@Catfish_Man) on Twitter:


Yay, macOS 10.13.2 is out. Among a lot of other things, it fixes a bug that could, in a somewhat elaborate series of circumstances, cause NSUserDefaults to think all preferences are null.


Symptom is that after two simultaneous reads (including reads by framework code), future reads could return nil.


Basically, two threads need to miss the local cache simultaneously. Normally this is prevented by a lock. I was never able to make it happen myself, even in contrived tests, without modifying CF to make it more likely. Still happened in the wild though.


Amusingly, this bug is like 4 years old. It was just really hard to trigger for most of that time so nobody discovered it.


Even after all this time it amazes me how something can be nigh-impossible to reproduce in a controlled test, and yet pop up all over the place in the wild :/

0
Macho Man Randy Savage OP
Dec ’17

Very happy to hear that I can expect this issue to be fixed when I upgrade to 10.13.2. I wish they would have mentioned the fix in the release notes, but in any case, thanks a lot Apple.

0
gnachman OP
Dec ’17

My radar also got duped to 34819526. Here's my report: https://openradar.appspot.com/radar?id=5039639916183552

0
Introspector OP
Dec ’18

A year has come to pass and the userDefaults are as buggy as they were then.


One simply cannot rely on the it and has to turn over backwards to work against the frameworks.


I thought those were there to help us ?

0
Serious problem with NSUserDefaults? stringForKey: returning nil, value is in user defaults
First post date Last post date
 
 
Q