Strange Error occurs since upgrading to XCode 10.2

Question

philmartin1983 OP

Created Apr ’19

Replies 8

Boosts 0

Views 11k

Participants 4

Since updating to XCode 10.2 we have started seeing crash reports with the exceptions,

NSException: -[__NSCFNumber member:]: unrecognized selector sent to instance 0x8000000000000000

NSException: -[NSIndexPath member:]: unrecognized selector sent to instance 0x8000000000000000

NSException: -[__NSTaggedDate member:]: unrecognized selector sent to instance 0x8000000000000000

I've located the place in which the Exception happens, but I'm 100% sure that the dictionary in question doesn't have a IndexPath or a Date in it and the Memory address seems a little odd to me, its always the same. In fact at the point of the crash the dictionary has a valid key and the dictionary is valid.

In XCode 10.1 this doesn't happen, I've also found an article on Stack of one person who experienced a similar issue

'-[_NSCoreDataTaggedObjectID objectForKey:]: unrecognized selector sent to instance 0x8000000000000000'

and their app didn't even use core data!

They changed their Optimization Level from No Optimization to Optimise for speed -O would this have an impact, I'm about to try it but I wanted a 2nd opinion or some pointers that would cause the above.

Thanks

Answered by DTS Engineer in 358386022

I've located the place in which the Exception happens, but I’m 100% sure that the dictionary in question doesn't have a
IndexPath
or a
Date
in it

Right. This is common in situations like this. The issue is the object isn’t the right type, and thus you send a selector that’s appropriate for class

Foo

to an object of type

Bar

.

The most common cause of this problem is an over release bug. Imagine this sequence:

You allocate an object of type
```
Foo
```
.
You put it in a dictionary.
You accidentally over release that object, freeing its memory.
Later on, you allocate an object of type
```
Bar
```
. This uses the same memory as your previous object.
You pull the object that’s supposed to be of type
```
Foo
```
out of your dictionary. It’s actually of type
```
Bar
```
, so when you call a method appropriate for
```
Foo
```
you crash like this.

They changed their Optimization Level

Changing the optimisation level can mask problems like this, but it doesn’t actually fix them. A long time ago a wise developer once warned me: Bugs that mysteriously disappear will mysteriously reappear. You need to find the underlying cause of this bug.

To that end, I recommend that you apply the standard memory debugging tools. In particular, Zombies is usually good at helping track down this problem.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

Claude31 OP

Apr ’19

0x8000000000000000 is not the address of your object.

could you show the code where this error occurs ?

0

Answer 2

DTS Engineer OP

Apple

Apr ’19

Accepted Answer

I've located the place in which the Exception happens, but I’m 100% sure that the dictionary in question doesn't have a
IndexPath
or a
Date
in it

Right. This is common in situations like this. The issue is the object isn’t the right type, and thus you send a selector that’s appropriate for class

Foo

to an object of type

Bar

.

The most common cause of this problem is an over release bug. Imagine this sequence:

You allocate an object of type
```
Foo
```
.
You put it in a dictionary.
You accidentally over release that object, freeing its memory.
Later on, you allocate an object of type
```
Bar
```
. This uses the same memory as your previous object.
You pull the object that’s supposed to be of type
```
Foo
```
out of your dictionary. It’s actually of type
```
Bar
```
, so when you call a method appropriate for
```
Foo
```
you crash like this.

They changed their Optimization Level

Changing the optimisation level can mask problems like this, but it doesn’t actually fix them. A long time ago a wise developer once warned me: Bugs that mysteriously disappear will mysteriously reappear. You need to find the underlying cause of this bug.

To that end, I recommend that you apply the standard memory debugging tools. In particular, Zombies is usually good at helping track down this problem.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 3

philmartin1983 OP

Apr ’19

Wouldn't this happen all the time though? This only occurs randomly not all the time.

0

Answer 4

Claude31 OP

Apr ’19

If it is due to memory release, that can be caused by the system, hence appearing as random.

0

Answer 5

philmartin1983 OP

Apr ’19

I resolved this, after further investigation the issue wasn't with the dictionary I had first thought it was, it was todo with some code I was running in the didDetermineState delegate method (which also contained a dictionary) and was further down the stacktrace. So the initial the point in which it crashed was a red herring. Anyway all fixed, thanks for your comments

0

Answer 6

Claude31 OP

Apr ’19

happy for you and thanks for feedback.

That is one more illustration that it is essential to localize precisely where the error comes from (either with breakpoints, with print to log at various places…)

Don't forget to close the thread.

0

Answer 7

ytsai OP

May ’19

I also encountered same problem, and I found out this crash is due to ‘race condition’.

We can solve this problem by thread safety. (Modifying dictionary in a specific queue)

Maybe, dictionary handles thread safety issue before Xcode 10.2. But now it doesn’t. (Maybe)

By the way, I can also solve this problem by adding didSet in the dictionary object, and do nothing inside the didSet closure. But this is very weird to me. Can somebody tell me why?

0

Answer 8

DTS Engineer OP

Apple

May ’19

Maybe, dictionary handles thread safety issue before Xcode 10.2.

No. Swift dictionaries, and

NSDictionary

for that matter, are not thread safe. Specifically, it is not safe to modify a dictionary where there’s any possibility that another thread might be accessing it (either reading or modifying). Typically this means that, if you have a mutable dictionary, you must serialise all access to it.

The fact that this worked previously doesn’t mean all that much. It’s very common for threading errors like this to manifest due to other, unrelated changes. If you want to proactively flush out problems like this, Thread Sanitizer is your friend.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0