-
Notifications
You must be signed in to change notification settings - Fork 2
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
Crashes & out of memory #7
Comments
Dany gave me logs. "No errors or pop ups,but after returning from a chrome rendered link, Neebla looked like it restarted,landed me back to album list." He was wondering about memory usage in the app. I'm wondering if this is when BugSnag is reporting out of memory crashes. |
Running connected to the Xcode debugger, I tapped on a URL. Coming back, the app restarted. The debugger said "Message from debugger: Terminated due to signal 9". https://developer.apple.com/forums/thread/124389 https://developer.apple.com/forums/thread/655225 |
Results of showing open files when going into the background-- and get signal 9 at times in this case too: openFilePaths: ["/dev/null", "/dev/ttys000", "/dev/ttys000", "/private/var/mobile/Containers/Data/Application/D3778A59-9DAB-4B53-9D3E-8100F40E7DAC/Library/Application Support/com.bugsnag.Bugsnag/biz.SpasticMuffin.SharedImages/v1/kvstore", "?", "?", "/private/var/mobile/Containers/Shared/AppGroup/2A899802-F51E-4921-BD14-71E7F3CE6582/Documents/Neebla.SQLite.db", |
This was one just before going into the background and getting the signal 9: openFilePaths: ["/dev/null", "/dev/ttys000", "/dev/ttys000", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Application Support/com.bugsnag.Bugsnag/biz.SpasticMuffin.SharedImages/v1/kvstore", "?", "?", "/private/var/mobile/Containers/Shared/AppGroup/2A899802-F51E-4921-BD14-71E7F3CE6582/Documents/Neebla.SQLite.db", "/private/var/mobile/Containers/Shared/AppGroup/2A899802-F51E-4921-BD14-71E7F3CE6582/Documents/SyncServer.SQLite.db", "/private/var/mobile/Containers/Shared/AppGroup/2A899802-F51E-4921-BD14-71E7F3CE6582/Documents/logging/LogFile.txt", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Caches/biz.SpasticMuffin.SharedImages/Cache.db", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Caches/biz.SpasticMuffin.SharedImages/Cache.db-wal", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Caches/biz.SpasticMuffin.SharedImages/Cache.db-shm", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Caches/biz.SpasticMuffin.SharedImages/Cache.db", "/private/var/mobile/Containers/Data/Application/F4FA2CCC-447D-41B7-866A-4BB047D3FDBF/Library/Caches/biz.SpasticMuffin.SharedImages/Cache.db-wal", "/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.nsurlstoragedresources/Library/dafsaData.bin"] |
Here's what I'm using to get this:
So it seems this specific issue-- of tapping on a link and coming back to Neebla is not a file lock issue. This is also evidence that SQLite is not holding a file lock when the app goes into the background. |
A possibility for the overt crashes coming from Apple is that the SQLite db is in the shared container. https://inessential.com/2020/02/13/how_we_fixed_the_dreaded_0xdead10cc_cras These references don't raise any issue for using SQLIte in a shared container: andpor/react-native-sqlite-storage#308 File lock issue: https://developer.apple.com/library/archive/technotes/tn2408/_index.html "Solutions Issues with file protection flags General docs Given that I'm seeing wal and shm files it looks like my SQLite db is open in WAL mode. |
https://developer.apple.com/documentation/uikit/uiapplication/1623031-beginbackgroundtask You can call this method at any point in your app’s execution. You may also call this method multiple times to mark the beginning of several background tasks that run in parallel. However, each task must be ended separately. You identify a given task using the value returned by this method. See also: |
My next planned action is to do this: "the containing app (and all applications) should properly use background task assertions around file operations they require completed in a shared container (with or without extensions). This includes all writes or deletions. Such a process might still be killed by jetsam but at a much lower frequency." This should be relatively straight forward for iOSBasics as there are pretty well-defined entry points to this API. It will be tricker in the Neebla app itself, which uses a separate SQLite db. |
We'll, I've wrapped the main entry points for iOSBasics in a new |
https://developer.apple.com/documentation/xcode/diagnosing_issues_using_crash_reports_and_device_logs/identifying_high-memory_use_with_jetsam_event_reports https://developer.apple.com/forums/thread/73192 |
Next:
|
In TestFlight build 20210319.1 I've added some more usage of |
Result: Still crashes. In same manner. Get an album started downloading, put into the background, and fairly reliably get a crash. |
May want to add more backgroundAssertable's in NotificationCenter.default.addObserver's. Still getting: 2021-03-19T23:06:13-0600 debug : Image status: .loaded (from scaling) |
I have moved to using a single SQLite db (from one in the main app in one in iOSBasics). This is to: a) simplify things b) because it seemed like I wasn't seeing 2x WAL and SHM files open (which I would expect), and c) Admittedly not very extensive looking on stackoverflow seemed to indicate that multiple SQLIte dbs was inadvisable. The main possible problem with this is conflicting names of databases tables across Neebla and iOSBasics. |
That db change didn't help the crash issue. My next change is to not send local notifications in Neebla when the app is in the background. These drive the code in #7 (comment). My hypothesis is that when the network delegate methods get called in the backgound, the amount of work that can be done by the app is limited. And if you go over that, the system kills the app. |
Testing criteria: Getting all albums downloaded without a single crash reported from Apple-- using a TestFlight build. (Yes, this is a moving criteria, as it depends on the number of albums and their specific size and data parameters). I'm doing this by starting the download of an album, putting the app into the background, and (usually) turning off the screen. Wash, rinse, repeat.
Not sure if it's notable or not but the bulk (or all?) of these are coming while I'm downloading the computer album. Now starting to download the cats album.
|
All of these crashes I see so far in Apple crash reporting are still coming from |
TestFlight 20210320.1 testing: Got through a full round of downloads of all albums from scratch with no crashes! |
I'm trying to debug crashes and out memory indications.
The crash reports from Apple are around the time of database access.
E.g., see App crashes while doing background database operations stephencelis/SQLite.swift#1042
Crash reports from BugSnag are indicating out of memory. (WIth no traces).
The text was updated successfully, but these errors were encountered: