User Profile

The issue with the full database or disk happens because of a free space on the physical disk or inserted a large DB page size. I verified on the original iPad if a disk has a free space limit or app container has a large size for the SQLite migration process. The first test. The app container size is 9.3 GB. I removed data for 1.3 GB and total left 8 GB. I launched application with the copied and original WAL file. As a result, respectively, the logs shows the same error and CoreData stack is freeze. The second test, I removed the moved myDB2.sqlite-wal file (original file with the CoreData freeze) and left just a copied myDB.sqlite-wal. The myDB2.sqlite-wal file has 282.1 MB. The CoreData stack successfully initialized and no errors in the CoreData/SQLite. Looks like a problem was around the original WAL file that was not accessible by the CoreData and by the export file option. Currently, the possible solution for the CoreData freze is: Move WAL file under new name. Copy moved WAL file under the original name. Remove moved WAL file Init CoreData stack

I decided to apply my previous attempts on the original WAL file. First, the checkpoint forcing via journal_mode=DELETE doesn't work for the original WAL file. The CoreData is freeze and file is not removed at the end of session. Second, I moved (didn't copy) original file under different name myDB2.sqlite and the CoreData stack init is freeze again. Interesting in my previous tests that the copied file with the same name was opened but with periodic errors. Third, If the original file is moved and copied to the path with initial name then the CoreData stack initialized successfully and opened the DB. The addPersistentStoreWithType:configuration:URL:options:error: func started to return the error: ... CoreData: error: sourceURL : file:///var/mobile/Containers/Data/Application/08D158CE-7216-4271-A3F2-AF3E4E5DA772/Documents/myDB.sqlite CoreData: error: reason : Cannot migrate store in-place: error during SQL execution : database or disk is full CoreData: error: destinationURL : file:///var/mobile/Containers/Data/Application/08D158CE-7216-4271-A3F2-AF3E4E5DA772/Documents/myDB.sqlite CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134110 "An error occurred during persistent store migration." UserInfo={NSSQLiteErrorDomain=13, NSFilePath=/var/mobile/Containers/Data/Application/08D158CE-7216-4271-A3F2-AF3E4E5DA772/Documents/myDB.sqlite, NSUnderlyingException=error during SQL execution : database or disk is full, reason=error during SQL execution : database or disk is full} CoreData: error: storeType: SQLite CoreData: error: configuration: (null) CoreData: error: URL: file:///var/mobile/Containers/Data/Application/08D158CE-7216-4271-A3F2-AF3E4E5DA772/Documents/myDB.sqlite CoreData: annotation: options: CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1 CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1 It happens when the CoreData attempts to migrate a store and SQL disk space estimation throws error. I am not sure if it happens because if the migration or the last SQL commit request. The last SQL commit request has a lot of CREATE INDEX for every table, DELETE and INSERT new BLOB data to the Z_METADATA and Z_MODELCACHE tables: CoreData: sql: CREATE INDEX IF NOT EXISTS Z_Table1_Table2_Attribute1 ON ZTABLE1 (ZTABLE2 COLLATE BINARY ASC, ZATTRIBUTE1 COLLATE BINARY ASC) CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'ANSSQLITEINDEXSTATISTICS' CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'ACHANGE' CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_METADATA' CoreData: sql: DELETE FROM Z_METADATA WHERE Z_VERSION = ? CoreData: details: SQLite bind[0] = 1 CoreData: sql: INSERT INTO Z_METADATA (Z_VERSION, Z_UUID, Z_PLIST) VALUES (?, ?, ?) CoreData: details: SQLite bind[0] = 1 CoreData: details: SQLite bind[1] = "51083DD1-5CBD-4F94-AF82-74684B6C5A07" CoreData: details: SQLite bind[2] = <NSData len=3259> CoreData: annotation: Saving new meta data; version = 1 ; UUID = 51083DD1-5CBD-4F94-AF82-74684B6C5A07 CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_MODELCACHE' CoreData: sql: DELETE FROM Z_MODELCACHE CoreData: sql: INSERT INTO Z_MODELCACHE (Z_CONTENT) VALUES (?) CoreData: details: SQLite bind[0] = <NSData len=41191> CoreData: annotation: Saving new model cache CoreData: sql: COMMIT CoreData: error: (13) database or disk is full CoreData: annotation: Disconnecting from sqlite database due to an error. CoreData: annotation: Disconnecting from sqlite database. CoreData: annotation: Disconnecting from sqlite database. CoreData: error: addPersistentStoreWithType:configuration:URL:options:error: returned error NSCocoaErrorDomain (134110) ... The 13 error from SQLITE is : #define SQLITE_FULL 13 Insertion failed because database is full Other iPad devices with copied files finish the migration successfully with the same logs (without error) and WAL has zero size: ... CoreData: annotation: Saving new model cache CoreData: sql: COMMIT CoreData: sql: pragma wal_checkpoint(truncate) CoreData: annotation: sql execution time: 0.0028s CoreData: annotation: Disconnecting from sqlite database. The error can happen when: An attempt to insert new data that would cause the database file to grow larger than Maximum Number Of Pages In A Database File. In my DB now 2856 number of pages. The inserted page size larger than the default value - 4096 bytes. How to found the page size that the migration tries to insert? Why one iPad can migrate but another not? The App container is the same.

I noticed a CoreData error when keeps app working with the copied sqlite files. The console shows: CoreData: error: (13) database or disk is full CoreData: annotation: Disconnecting from sqlite database due to an error. CoreData: error: SQLCore dispatchRequest: exception handling request: <NSSQLSaveChangesRequestContext: 0x2838cf480> , error during SQL execution : database or disk is full with userInfo of { NSFilePath = "/var/mobile/Containers/Data/Application/77B8EAB6-120F-4E4D-AE96-EDC81258A250/Documents/myDB2.sqlite"; NSSQLiteErrorDomain = 13; } It happens randomly and multiple times after different CoreData activities: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'ACHANGE' SELECT all columns from the regular table. SQLite bind[2] = "" SQLite: EXPLAIN QUERY PLAN SELECT sql: COMMIT Fetching 13543 rows Is it mean that the iPad doesn't have enough disk or RAM space? The iPad storage shows 26 GB of 128 GB used and application alocated only 48 MB RAM. I don't see the same errors on a different iPad with the same copied files.

Verified any differences between sqlite files before/after using PRAGMA options: journal_mode=DELETE wal_checkpoint=FULL These options force checkpointing from WAL file to sqlite file. I want to know what kind transactions was applied, if it's migration issue. In result, the sqldiff myDB.sqlite myDB2.sqlite doesn't show any difference and 1 - will remove the WAL file, 2 - keeps WAL file without modifications in size or date.

I tried to export the WAL file after coping the original file to a new one with a different name. Yes, I can export myDB2.sqlite-wal file and it's identical. NSString *pathOld = @".../myDB.sqlite-wal"; NSString *pathNew = @".../myDB2.sqlite-wal"; [[NSFileManager defaultManager] copyItemAtPath:pathOld toPath:pathNew error:nil]; If all files are imported to the different iPad then the CoreData freeze is NOT experienced. If to initialize CoreData stack with the copied files on the same iPad (where the issue is reproducible) then the CoreData freeze is NOT experienced! The original WAL file still have the issue. The access permission can be changed on the WAL file but it's similar what sqlite has: NSFileExtensionHidden = 0; NSFileGroupOwnerAccountID = 501; NSFileGroupOwnerAccountName = mobile; NSFileModificationDate = "2022-12-03 01:39:41 +0000"; NSFileOwnerAccountID = 501; NSFileOwnerAccountName = mobile; NSFilePosixPermissions = 420; NSFileProtectionKey = NSFileProtectionCompleteUntilFirstUserAuthentication; NSFileReferenceCount = 1; NSFileSize = 282108792; NSFileSystemFileNumber = 285206; NSFileSystemNumber = 16777220; NSFileType = NSFileTypeRegular;

I found that the sqlite-wal file exists so far the DB session is opened but it's still on the iPad disk storage even the iOS app is force closed. This file keeps transactions that were previously committed to the DB. The WAL file is not removed because SQLite journal mode prevents database corruption. If the application is crashed in the middle of a checkpointing operation. Then the database file .sqlite is in an invalid state unless joined with a new data contained in the WAL. The file can be removed by SQLite when it finished checkpoint. I cannot copy this file from the iPad on my mac book via the iExplorer app or Xcode -> Download Container, it's immediately disappear (or never copied). That why original iPad can reproduce this issue but other iPad with copied files cannot. Is it possible that the WAL file keeps bad DB status and next app execution freezes at the first `SELECT' query? How to resolve it? Can I fix the CoreData freeze if to open the database with the DELETE journal mode pragma? This will checkpoint and then delete the WAL file for me. @{ NSSQLitePragmasOption: @{ @"journal_mode": @"DELETE"}}; Thanks

Hello kimi.wu,We can see the same issue in our app. It happened 66 times in the last 30 days on iPad/iPhone with iOS 13 - 13.1.3.Did you submit a bug report to Apple?Currently, I don't have any solutions or tips too. The crash report is not informative.Do you have any idea about this bug?Thanks,Anatoli

We continue to see crashes in the VectorKit code. The reports show that iOS 12 and 13 still have this issue. Reported to Apple again.