I’m building a phone app and we’re trying to have the option of loading a prebuilt database instead of syncing. The regular database seems to copy fine but the sync database seems like it is not. The database is about 4 GB but after the Database.copy call completes, when I look in ADB, the sqlite3 file is only 2 GB.
I can’t for the life of me figure out why it won’t copy the whole sqlite3 file. Any advice would be great.
Yea so the database in question should be the one generated from pulling from the sync gateway. We technically have two databases [app-name].cblite2 and [app-name]-sync.cblite2. The one that does not seem to finish is the sync one.
So if I try to access the database via say, a query on the count of a type of document, I see error messages about the database disk image is malformed, specifically sqlite error code 11. Also, since the sqlite3 file is missing almost 2 GB, I’m assuming something is not getting copied over. I don’t see any errors with the Database.copy command itself, even with logging turned up.
I had initially been running this on the UI thread but I have since moved it to a background thread and I still don’t see the 4 GB file fully copied.
The last line is my own print statement which prints after Database.copy call. The only thing I see is 0 pages free but that seems to be preclose so after the copying? Are there any other logs you need to see?
I’ve also used the cblite tool and it does read the database as follows:
C:\Users\800061\AppData\Local\Android\Sdk\platform-tools>cblite file [app name]-sync.cblite2
Database: .[app name].cblite2
Total size: 4GB
Documents: 39791, last sequence 39791
Indexes: xType_index
UUIDs: public f0f66f8c928e45e5ab7df445872cf6ec, private c0bbd24be6ea44eaa472e7c9c9d3511a
That is the correct number of documents that I would expect and the total size lines up as well. I’ll try using the tool to run some queries just to make sure that nothing is corrupted but as it stands, I still feel like something is stopping the Database.copy call from finishing since it only grabs 2GB and I think the missing 2GB is what is leading to the corruption.
After the database file is copied to a temporary folder, we open and close it before moving it to the destination. In that process, apply SQLite3’s optimization pragma, “optimize” and “vaccum”. It appears that this process corrupted file, “image malformed.”
We have moved to 3.0 now. Do you have plan to move to 3.0?
I’ll try and see if we can scrub a database for you guys to test but in the meantime, I was able to update CBL to 3.0 in a test setting. When I run database.copy, it does seem like it now copies all of the sqlite3 file as I can see the 3.9 GB. Additionally, when I use the cblitetool, the document counts are correct. However, I still see database image corrupt errors.
2022-03-28 15:43:17.292 24323-31082/com.[app name] E/CouchbaseLite/DATABASE: database disk image is malformed (11/11)
2022-03-28 15:43:17.292 24323-31082/com.[app name] E/CouchbaseLite/DATABASE: database disk image is malformed (11/11)
2022-03-28 15:43:17.292 24323-31082/com.[app name] I/CouchbaseLite/DATABASE: RELEASE SAVEPOINT roTransaction
2022-03-28 15:43:17.295 24323-31082/com.[app name] E/Auditing: [count] couchbase lite exception is 15: data is corrupted
Definitely better in 3.0, but, unfortunately, there’s still problem of corrupt data. It would be greatly helpful to us if you could scrub a file for us to repro on our side. Once I receive the file, I will create a ticket for it.
We may have seen this issue before. We think it happens on Android (we have seen it in Xamarin Android).
We are unable to reproduce it. @jianminzhao was unable to repro it with the DB you provided and I have been unable to repro it with the DBs provided by others.
Our conclusion is that this, most definitely, is an issue. We are, however unable to get a handle on it. Anything you can do to get us closer to reproducing it would be very, very appreciated.
What kind of device are you using? What version of Android are you running? Can you pull the busted DB off the device and get it to us?
I’m going to try again at a repro as soon as I get a spare moment. We are in the middle of a release, so I may not get back to you immediately. I’ve opened this ticket to track the issue: Loading...
We’re on a Galaxy S10 running Android Version 10. I can’t provide the original production database that saw the issue but I was able to replicate it with a sanitized database which is the one I gave to Jianmin. That particular database has some 300k documents and the sync.sqlite3 database ends up being a little over 8 GB. Our team was considering trying smaller database sizes so are in the process of generating sanitized databases of 200k and 100k. If that’ll help, I can send them to you when they are generated.
Thanks for taking a look at this. Let me know if I can provide anything else.