Aditi3
commented
3 years ago Hi @iaagg,
Allow me some time to examine the stack traces at my end and I will get back to you with an update shortly.
Closed iaagg closed 3 years ago
Aditi3
commented
3 years ago Hi @iaagg,
Allow me some time to examine the stack traces at my end and I will get back to you with an update shortly.
aakarshsasi
commented
3 years ago +1 Seeing several crashes for this recently but not able to reproduce.
Aditi3
commented
3 years ago I haven't been able to repro the crash at my end as well. I am still working on it to understand where the aforementioned crashes could happen. In case, I find anything meaningful, I will surely get it fixed in the upcoming SDK releases.
iaagg
commented
3 years ago If that helps I found some messages in our crash reports in Firebase.
It's about crash type №2 from the list in the initial message:
malloc: Non-aligned pointer 0x31656e6f6850690a being freed
Detected over-release of a CFTypeRef 0x28240c8e0 (0 / Not A Type)
Detected over-release of a CFTypeRef 0x282414d00 (7 / CFString)
Didn't find anything similar to this in other crash types reports
iaagg
commented
3 years ago @Aditi3 sorry, but maybe you need any additional info for this one? Two of these 3 crashes are in our TOP 5 for a month period and affect our app stability significantly 😢
Aditi3
commented
3 years ago @iaagg @aakarshsasi Thanks for sharing the details! I have made some modifications to mitigate the crashes as our best bet here considering crash(s) is not reproducible.
We have already added changes in our release branch. You can expect a release by the end of this month.
aakarshsasi
commented
3 years ago @Aditi3 any updates on when the release will be out?
Aditi3
commented
3 years ago At present, the upcoming version 3.9.3 is in the QA phase and planned to go out early next week.
aakarshsasi
commented
3 years ago @Aditi3 any updates? Wasn't it supposed to go out this week? The crash rates are one of the top three for this crash in our app :/
aakarsh-sasi
commented
3 years ago Updated to 3.9.3 but the crash is still happening.
iaagg
commented
3 years ago Confirm all 3 crashes reported in the initial message still reproduce after the update to 3.9.3
Aditi3
commented
3 years ago I will take another look at this and try again to reproduce the crash.
In the meantime, if anyone has repro steps and share the same with us then we would surely get it fixed in the upcoming SDK release.
iaagg
commented
3 years ago Hello @Aditi3 Apparently,
we managed to fix this on our side by applying this fix to our fork of CleverTap ios SDK. We found out that generateAppFields method can be called from two different threads (on main thread on app launch from recordAppLaunched method, and on internal clever tap serial queue), which resulted sometimes to threadsafety issue during accessing properties of CTDeviceInfo. We also noticed some properties marked as atomic, but due to overridden getters atomicity is lost, since it should be implemented by developer in case of overriding.
Looks like all crashes happened on accessing atomic model property of CTDeviceInfo and synchronising access to it fixed the problem.
We do consider these changes as a temporary solution, since in our opinion the proper fix should be applied on the level of CleverTap object, but I guess it will be your decision.
We will wait for further updates of SDK, hopefully with fix, meanwhile we are good to proceed with our local solution.
diff --git a/Pods/CleverTap-iOS-SDK/CleverTapSDK/CTDeviceInfo.m b/Pods/CleverTap-iOS-SDK/CleverTapSDK/CTDeviceInfo.m
index 9d340b5b5..e2ca58b80 100644
--- a/Pods/CleverTap-iOS-SDK/CleverTapSDK/CTDeviceInfo.m
+++ b/Pods/CleverTap-iOS-SDK/CleverTapSDK/CTDeviceInfo.m
@@ -117,11 +117,16 @@ - (NSString *)description {
}
- (NSString *)deviceId {
- return _deviceId ? _deviceId : self.fallbackDeviceId;
+ [deviceIDLock lock];
+ NSString *tmpId = [(_deviceId ? _deviceId : self.fallbackDeviceId) copy];
+ [deviceIDLock unlock];
+ return tmpId;
}
- (void)setDeviceId:(NSString *)deviceId {
+ [deviceIDLock lock];
_deviceId = deviceId;
+ [deviceIDLock unlock];
}
- (BOOL)isErrorDeviceID {
@@ -371,8 +376,10 @@ - (NSString *)manufacturer {
}
- (NSString *)model {
- if (!_model) {
- _model = [[self class] getPlatformName];
+ @synchronized (self) {
+ if (!_model) {
+ _model = [[self class] getPlatformName];
+ }
}
return _model;
}
@@ -400,8 +407,10 @@ - (NSString *)deviceHeight {
}
- (NSString *)deviceName {
- if (!_deviceName) {
- _deviceName = [UIDevice currentDevice].name;
+ @synchronized (self) {
+ if (!_deviceName) {
+ _deviceName = [UIDevice currentDevice].name;
+ }
}
return _deviceName;
}
Hey @iaagg Thank you for suggesting a solution and working on this.
Theoretically, the proposed solution makes sense to me and I'm looking forward to implementing the changes in our development branch.
I will get back to you with a summary of my quick testing and tentative release date.
Thanks again!
Aditi3
commented
3 years ago Thank you all for your support here. We have merged the changes in our development branch and will be shipping in the next SDK release.
aakarsh-sasi
commented
3 years ago When will v3.10.0 be released?
Aditi3
commented
3 years ago @aakarsh-sasi We're aiming to release on coming Monday.
Describe the bug Different crashes caused by the same method
generateAppFieldsEnvironment We have CleverTap plugged in via Segment, using CleverTap Segment iOS SDK 1.1.8 And therefore we are using CleverTap iOS SDK 3.9.2
Additional context Crashes appeared after we updated to CleverTap Segment iOS SDK 1.1.6 And therefore we were using CleverTap iOS SDK 3.9.0
So update to the latest version didn't help, crashes still appear. We can't reproduce them though.
Stack traces Crash type №1
Crash type №2
Crash type №3
Please let me know if you need any additional information