Crash with Couchbase Lite .NET during initial upgrade path


I just updated my Xamarin iOS mobile app from 1.1.2 to and I’m noticing during upgrade test scenarios that on the first initial launch of the app, there is a crash at the splash screen. After the initial crash, restarting the app works as expected with no additional crash. Has anyone seen this or know what the root cause may be? Reverting the library back to 1.1.2 and executing the same app upgrade scenario seems to be fine.

Crash log does not have any stack trace or exceptions:
Exception Type: SIGABRT
Exception Codes: #0 at 0x18133c140
Crashed Thread: 0


I was able to track down the exception…it looks like an io exception during the upgrade. This is how I’m creating my manager instance, I need to specify a particular path to where I want the database to be:

var dbDirInfo = Directory.CreateDirectory (dbPath);
_manager = new Manager (dbDirInfo, ManagerOptions.Default);

[2016-03-08T13:35:34.9721230-06:00] [debug] Source and destination path must be different.
[2016-03-08T13:35:34.9746950-06:00] [debug] at System.IO.Directory.Move (System.String sourceDirName, System.String destDirName) <0x100473528 + 0x00250> in :0
at Couchbase.Lite.Db.DatabaseUpgraderFactory+v1_upgrader.Import () <0x100ce8b50 + 0x004ef> in :0
at Couchbase.Lite.Manager.UpgradeDatabase (System.IO.FileInfo path) <0x100cdf1e0 + 0x0021b> in :0
at Couchbase.Lite.Manager.UpgradeOldDatabaseFiles (System.IO.DirectoryInfo dirInfo) <0x100c005cc + 0x0004f> in :0
at Couchbase.Lite.Manager…ctor (System.IO.DirectoryInfo directoryFile, Couchbase.Lite.ManagerOptions options)


@borrrden Is this a known issue or is there a workaround I am missing?


It’s not a known issue, but it is now. I’ve verified that the upgrade process works correctly, but there is a bug in the post-upgrade logic. It tries to move the files from the “tmp” directory to the “real” directory (because that’s what is needed when you use the “ReplaceDatabase” API) but in the case of automatic upgrades those two directories are the same since it is done in place. It is safe to catch and ignore this exception and I will put a fix into 1.2.1 and master (I’ve filed this issue about it)


If I catch and ignore the exception, the data in my “old” database should still be in-place and available with no data loss since in the two directories are the same?


You should of course also do verifications yourself, but from what I have seen the data is intact. The problem stems from having two ways to upgrade a database. Here is one way:

ReplaceDatabase API
Source DB copied to tmp directory
DB in tmp directory upgraded to newest version
DB in tmp directory moved to destination directory

And here is the “automatic” way:

Manager is created and scans its folder for older database files, and finds one
The manager upgrades the database to the newest version (which in the case of 1.1 -> 1.2 just means moving some files around since there is no schema change)
DB in tmp directory moved to destination directory <— This step should not happen, because it is already in the destination directory.

I’ve already committed a fix. All I needed to do was check that the two paths are not already the same.


I did some testing and verified that data did retain across upgrade regardless of whether I handle the exception or not. Catching the exception and ignoring it is the workaround to prevent app crashes. Also the exception only occurs once (first time app starts with the updated library) and does not happen anytime after that.