Closed leandromperez closed 4 years ago
I'm already seeing this a lot after I've upgraded to the version 3.7.0. I can also see this happening on iOS 13 devices.
Same issue here, pls fix it!
We've prioritized this and are looking into it.
does anyone happen to have logs for this? The log it spits out would include the exact error it's getting ...
- (NSData *_Nullable)dataFromPlist:(nonnull id)plist
{
NSError *error = nil;
NSData *data = [NSPropertyListSerialization dataWithPropertyList:plist
format:NSPropertyListXMLFormat_v1_0
options:0
error:&error];
if (error) {
SEGLog(@"Unable to serialize data from plist object", error, plist);
}
return data;
}
@zzzworm @J-Mendes @leandromperez
Have the same or related crash in 3.7.0 version
There will be no log printed as that function crashes before SEGLog is executed
Specifically at line
NSData *data = [NSPropertyListSerialization dataWithPropertyList:plist ...
My crash stack trace is almost the same with this error: EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000b5d617be5490
0 libobjc.A.dylib 0x1b5f2b028 objc_retain + 8
1 CoreFoundation 0x1b60c8208 -[__NSArrayM replaceObjectsInRange:withObjects:count:] + 172
2 CoreFoundation 0x1b6159048 _CFAppendXML0 + 2684
3 CoreFoundation 0x1b6159170 _CFAppendXML0 + 2980
4 CoreFoundation 0x1b6159170 _CFAppendXML0 + 2980
5 CoreFoundation 0x1b6158ed8 _CFAppendXML0 + 2316
6 CoreFoundation 0x1b6155464 _CFPropertyListCreateXMLData + 184
7 CoreFoundation 0x1b61574d4 CFPropertyListCreateData + 216
8 Foundation 0x1b64d7e20 +[NSPropertyListSerialization dataWithPropertyList:format:options:error:] + 48
9 Analytics 0x1031da318 -[SEGFileStorage dataFromPlist:] + 149 (SEGFileStorage.m:149)
@sergiymomot ah, thanks for the clarification. I'd guess something is getting added that can't be deserialized maybe. are you seeing this locally, or just seeing it in your crash reporting tools?
@bsneed Only in Crashlytics Couldn't reproduce it locally
It happened for about 100 users in a month, so it is pretty rare, but still annoying Also it happens once per person from what I see, so it might be a one-time data mismatch
I just catch the log from debug. see:
2019-11-14 13:39:13.612370+0800 Himalaya[18617:4501255] Running: registeredForRemoteNotificationsWithDeviceToken: with arguments ( {length = 32, bytes = 0xce20a703 2ee2772d 76809052 5b0e7968 ... 42e21076 87612780 } ) on integration: Segment.io 2019-11-14 13:39:13.622064+0800 Himalaya[18617:4501247] 💛 13:39:13.6200:IterableAPIInternal:register(token:appName:pushServicePlatform:notificationsEnabled:onSuccess:onFailure:):180: sending registerToken request with args [AnyHashable("preferUserId"): true, AnyHashable("userId"): "913808", AnyHashable("device"): ["platform": "APNS_SANDBOX", "dataFields": ["userInterfaceIdiom": "Phone", "localizedModel": "iPhone", "identifierForVendor": "C2F1BFE4-3AFF-4D6F-9732-1C8EEFE4B78C", "appBuild": "3226", "systemVersion": "13.2", "iterableSdkVersion": "6.1.2", "deviceId": "F68CC888-CADC-455D-99BA-EBA98AAC728F", "model": "iPhone", "systemName": "iOS", "appPackageName": "com.ximalaya.xmlyi", "appVersion": "2.3.70", "notificationsEnabled": true], "applicationName": "himalaya_dev", "token": "ce20a7032ee2772d768090525b0e79686000fad7652d83e042e2107687612780"]] 2019-11-14 13:39:13.625564+0800 Himalaya[18617:4501380] Running: identify: with arguments ( "<SEGIdentifyPayload: 0x12b23fee0>" ) on integration: Segment.io 2019-11-14 13:39:13.629688+0800 Himalaya[18617:4501380] push granted 2019-11-14 13:39:13.630061+0800 Himalaya[18617:4500956] didRegisterForRemoteNotificationsWithDeviceToken ce20a7032ee2772d768090525b0e79686000fad7652d83e042e2107687612780 2019-11-14 13:39:13.631347+0800 Himalaya[18617:4500956] !!!! push token ce20a7032ee2772d768090525b0e79686000fad7652d83e042e2107687612780 2019-11-14 13:39:13.635543+0800 Himalaya[18617:4501379] Running: registeredForRemoteNotificationsWithDeviceToken: with arguments ( {length = 32, bytes = 0xce20a703 2ee2772d 76809052 5b0e7968 ... 42e21076 87612780 } ) on integration: Segment.io 2019-11-14 13:39:13.637265+0800 Himalaya[18617:4501230] *** -[CFString _fastCharacterContents]: message sent to deallocated instance 0x12b23a310
and the crash stack:
Thread 11 Queue : io.segment.analytics.segmentio (serial)
other stacks:
Thread 1 Queue : com.apple.main-thread (serial)
Thread 3#0 0x00000001a7b33ab4 in workq_kernreturn () gputools.smt_poll.0x10d802080 (4)#0 0x00000001a7b33278 in semwait_signal ()
gputools.smt_poll.0x10d906490 (5)#0 0x00000001a7b33278 in __semwait_signal ()
Thread 6#0 0x00000001a7b33ab4 in __workq_kernreturn () Thread 7 Queue : com.apple.NSURLSession-work (serial)
Thread 8#0 0x00000001a7b33ab4 in __workq_kernreturn () com.apple.uikit.eventfetch-thread (9)#0 0x00000001a7b10c04 in mach_msg_trap ()
Thread 11 Queue : io.segment.analytics.segmentio (serial)
Thread 12#0 0x00000001a7b33ab4 in __workq_kernreturn () Thread 13 Queue : com.apple.CFNetwork.LoaderQ (serial)
Thread 14#0 0x00000001a7b33278 in __semwait_signal ()
com.apple.NSURLConnectionLoader (15)#0 0x00000001a7b10c04 in mach_msg_trap ()
Thread 16#0 0x00000001a7b33ab4 in __workq_kernreturn () Thread 17#0 0x00000001a7b32ccc in __psynch_cvwait ()
Thread 18#0 0x00000001a7b33ab4 in workq_kernreturn () Thread 19#0 0x00000001a7b33ab4 in __workq_kernreturn () Realm notification listener (20)Thread 21#0 0x00000001a7b33ab4 in workq_kernreturn () Thread 22 Queue : com.google.fira.worker (serial)
Thread 25#0 0x00000001a7a59c74 in start_wqthread () Thread 26#0 0x00000001a7a59c74 in start_wqthread () Thread 27#0 0x00000001a7b33ab4 in __workq_kernreturn ()
I'll leave this open until we push out a beta containing the fix.
@bsneed The fix using try/catch you pushed didn't work as the issue is not related to unhandled exception. It still crashes for me in production.
@sergiymomot please try master. Follow on changes remove the usage of the plots serialization stuff. It would really be helpful if you continue to see it to grab the counts of the payload you’re attempting to serialize. I’m flying blind without data.
Any update on this issue? Did master solve this crash?
@bsneed When I tried master, I got a crash below. It always happens first time the new version is run on a device. Second time it is fine. Tried on 3 physical devices and simulator - same result. So, unfortunately, I cannot push that to App Store.
@sergiymomot can you look at the setupWithConfiguration call? Looking at iOS innards for dispatch doesn't shed any light on what's happening here.
@bsneed more screenshots:
I just posted a fix for the conversion issue there's happening there. It's on the branch bsneed/LIB-1554
. You can try it out by setting this in your pod file:
pod 'Analytics', :path => '../myclone/analytics-ios'
Please let me know if any other issues crop up. Thanks!!
I just posted a fix for the conversion issue there's happening there. It's on the branch
bsneed/LIB-1554
. You can try it out by setting this in your pod file:
pod 'Analytics', :path => '../myclone/analytics-ios'
Please let me know if any other issues crop up. Thanks!!
Hello @bsneed ! Thanks for the fix, it seems to be working in my case. But are there any updates on the issue? Maybe someone should make a pull request to merge it into master? To make it more convenient.
@arietis this change is already in the latest beta.
Hi, We're seeing several crashes with the following stack trace:
The crashes occur in background threads.
Any ideas on what might be the issue?