- Mark as New
- Follow
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report
(From Kamil Kocemba on our former forum platform, 1 Nov 2016)
Unfortunately we aren't able to reproduce it reliably either. It does happen fairly often to our customers though. We have tens of thousands of crash reports from ITC and that's only coming from users who opted-in to provide that data. None of the crash reports specifies responsible thread. The app gets killed so it shows as crash in `main()`. I've however gone through what we have and here's my analysis:
- Every crash is caused by `SIGKILL` with `0xdead10cc` reason code which is received in `main()` on main thread - it looks like the app was in background, because all active threads seem to be spawned from a schedule and there is no trace of app or foreground activity
- There are multiple other threads, but all of them, except for one, is either sleeping (`__psynch_cvwait`, `__semwait_signal`) or gets killed (`mach_msg_trap`) at the time of crash
- The one running thread is accessing `sqlite3` database at the time of crash (`fsync` or `__guarded_open_np`)
So the only 2 things that are consistent in all these reports are:
- 1. `SIGKILL 0xdead10cc`
- 2. That lone thread that was running and trying to access the database.
Which makes me believe that's the thread worth investigating. Methods causing access seem to come from:
- `__38-[ADBAnalyticsWorker queue:timestamp:]_block_invoke + 108`
- `__29-[ADBHitQueueBase deleteHit:]_block_invoke + 56`
- `__29-[ADBHitQueueBase deleteHit:]_block_invoke + 48`
Now there's question about `0xdead10cc` and accessing *system resource*. Database is not a system resource. But perhaps resources in a shared container are now considered system resources. I know it's vague but I was told that *"someone from Apple said"* that access to such resources from background has to be now wrapped in a background task. I'm not sure if that's official response from DTS, I'll report back once I find out. If I'm correct, I'd imagine that it should be relatively straightforward to reproduce the issue by:
- Creating an app that stores all the data in a shared container
- Triggering one of the methods from SDK mentioned above while in background (be it `dispatch_after` or any other way)
If you know how to achieve this using public methods in the SDK, I'm happy to try it out myself. I'm sorry for lots of guesswork but I don't really know what else I can do at this point. One way to definitely disprove it would be to ship an app version without the SDK, but it seems like absolutely last resort. I'm quite determined to find a fix or workaround, because it affects tens of thousands of users each day. Let me know if there is anything I can do to help.
Views
Replies
Total Likes