I've just integrated OneSignal into my team's iOS app, and have started seeing the following crash when invoking +[OneSignal sendTags]:
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000899febeb8
Relevant stack frames:
0. Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x186964150 objc_msgSend + 16
1 CoreFoundation 0x187ddc47c -[NSMutableDictionary addEntriesFromDictionary:] + 252
2 myapp 0x10088f46c +[OneSignal sendTags:onSuccess:onFailure:] (OneSignal.m:627)
3 myapp 0x10088f378 +[OneSignal sendTags:] (OneSignal.m:617)
4 myapp 0x10017896c OneSignalTagManager.sendDeviceTags() -> () (OneSignalTagManager.swift)
5 myapp 0x1001789d8 @objc OneSignalTagManager.sendDeviceTags() -> () (OneSignalTagManager.swift)
So it looks like it's crashing on -[NSMutableDictionary addEntriesFromDictionary:] and I'm not sure why.
I haven't been able to reproduce this locally, but it's happening to a non-insignificant number of our users. The code path that's being followed to get here always produces a dictionary that maps strings to strings and doesn't allow nulls, so I don't think it's a problem there.
It looks like the OneSignal SDK had a similar problem in #222 that might be related.
Thanks for the help.
@0x7fffffff I reviewed the SDK code and this could happen in very rare cases if you are calling sendTags from another thread. To avoid this issue always make sure you are calling sendTags from the main thread.
We will investigate adding locking around this to prevent the exception.
@0x7fffffff closing this issue due to inactivity. It appears that calling sendTags from the main thread should resolve the issue. If you are still encountering this problem, please feel free to respond.
Unfortunately, calling sendTags from the main thread does not solve this problem @Nightsd01. All of my interaction with OneSignal tags has been using the code below for months and has been consistently crashing since this issue was first reported. OneSignalTag in the code below is nothing more than an enum wrapper to hold keys for tags, so this should help make the problem clear.
I've also never had the assertion below get triggered in my months of development and testing this application.
extension OneSignal {
class func sendCustomTag(_ tag: OneSignalTag, value: Any) {
assert(Thread.isMainThread)
// All calls to OneSignal tag sending must be done from the main thread
guard Thread.isMainThread else {
DispatchQueue.main.async {
sendCustomTag(tag, value: value)
}
return
}
// Call the build in OneSignal sendTags class method
sendTags([tag.description: value])
}
}
@Nightsd01 It's also worth mentioning that in my original (and new) stack traces, it is being reported that the crash is happening on the main thread. How should I proceed?
@0x7fffffff I suspect this has something to do with your tags code.
Have you still been unable to reproduce the issue?
Are you using an SDK like Crashlytics? If so, can you try logging the tag key/value pair so we can see if a specific tag is causing the crash perhaps?
Closing this issue due to inactivity. If you are still encountering the issue, please feel free to respond
Most helpful comment
@0x7fffffff I reviewed the SDK code and this could happen in very rare cases if you are calling
sendTagsfrom another thread. To avoid this issue always make sure you are callingsendTagsfrom the main thread.We will investigate adding locking around this to prevent the exception.