Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: OneSignalUserDefaults Crash Take II #1440

Open
1 task done
danhalliday opened this issue May 23, 2024 · 2 comments
Open
1 task done

[Bug]: OneSignalUserDefaults Crash Take II #1440

danhalliday opened this issue May 23, 2024 · 2 comments

Comments

@danhalliday
Copy link

danhalliday commented May 23, 2024

What happened?

The crash I reported in #1365 is still present in the 5.1.6 release. I’m reporting it again here because the previous issue was closed.

Steps to reproduce?

No idea. This is a remote crash report from Crashlytics.

What did you expect to happen?

The library should not cause a crash, regardless of what I may be doing wrong in using it.

OneSignal iOS SDK version

5.1.6

iOS version

17

Specific iOS version

No response

Relevant log output

Crashed: OneSignal.OSPropertyOperationExecutor
EXC_BREAKPOINT 0x00000001a3578168
0  CoreFoundation                 0x12168 __CFBasicHashRehash + 112
1  CoreFoundation                 0x11df8 __CFBasicHashAddValue + 100
2  CoreFoundation                 0x30a0 CFDictionarySetValue + 208
3  Foundation                     0x21534 _encodeObject + 660
4  Foundation                     0x210dc -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 460
5  Foundation                     0x200c4 -[NSDictionary(NSDictionary) encodeWithCoder:] + 572
6  Foundation                     0x2173c _encodeObject + 1180
7  OneSignalUser                  0xf1f4 block_destroy_helper + 6436
8  OneSignalUser                  0xf3ac block_destroy_helper + 6876
9  Foundation                     0x2173c _encodeObject + 1180
10 Foundation                     0x210dc -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 460
11 Foundation                     0x4ffc0 -[NSArray(NSArray) encodeWithCoder:] + 588
12 Foundation                     0x2173c _encodeObject + 1180
13 Foundation                     0x6f12a0 +[NSKeyedArchiver archivedDataWithRootObject:] + 104
14 OneSignalCore                  0xd69c -[OneSignalUserDefaults saveCodeableDataForKey:withValue:] + 88
15 OneSignalUser                  0x1f75c block_destroy_helper.32 + 27880
16 OneSignalUser                  0x1e0bc block_destroy_helper.32 + 22088
17 libdispatch.dylib              0x213c _dispatch_call_block_and_release + 32
18 libdispatch.dylib              0x3dd4 _dispatch_client_callout + 20
19 libdispatch.dylib              0xb400 _dispatch_lane_serial_drain + 748
20 libdispatch.dylib              0xbf30 _dispatch_lane_invoke + 380
21 libdispatch.dylib              0x16cb4 _dispatch_root_queue_drain_deferred_wlh + 288
22 libdispatch.dylib              0x16528 _dispatch_workloop_worker_thread + 404
23 libsystem_pthread.dylib        0x1f20 _pthread_wqthread + 288
24 libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Code of Conduct

  • I agree to follow this project's Code of Conduct
@nan-li
Copy link
Contributor

nan-li commented Jun 11, 2024

Hi @danhalliday I followed up on your other stacktrace reports.

I am not sure how these crashes could be happening, so I am still investigating.

Any additional information you can share will be helpful:

  1. Do you have updated data on frequency of these crash reports?
  2. Do you have data if the app is in the background or foreground?
  3. Do you have information about the memory usage or state of the memory at time of the crash? One possibility I am considering is the app being out of memory at the time we are saving information. Particularly if you know that there is high memory usage in the app already.

@danhalliday
Copy link
Author

I’m afraid my team has decided to drop OneSignal on the basis of these crashes, so I can’t devote any more time to investigating. But briefly:

  1. It’s about the same still, being roughly 1% of both users and sessions.
  2. It’s all foreground.
  3. I don’t have good data on that, all I have is the Crashlytics reports. I couldn’t discount something like that. But in general this app is not using a lot of memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants