sqlite3.c:60597: pagerOpenWalIfPresent: Assertion `pPager->eState==PAGER_OPEN' failed.

[rogerbinns]

Build apsw-sqlite3mc with --debug so assertions are enabled.

$ python3 -m apsw.mctests -v
APSW debug build: missing sys.apsw_fault_inject_control
testBackup (__main__.MultipleCiphers.testBackup)
Check backup restrictions ... ok
testBasic (__main__.MultipleCiphers.testBasic) ... ok
testCompileOptions (__main__.MultipleCiphers.testCompileOptions)
Check secure compilation flags were used ... ok
testKey (__main__.MultipleCiphers.testKey)
Ensure a key sticks ... ok
testMcIssue156 (__main__.MultipleCiphers.testMcIssue156)
Check memory mapping ... ok
testReadmeApplyEncryption (__main__.MultipleCiphers.testReadmeApplyEncryption)
readme apply_encryption ... python3: /space/mc/sqlite3/sqlite3.c:60597: pagerOpenWalIfPresent: Assertion `pPager->eState==PAGER_OPEN' failed.
Aborted (core dumped)

[rogerbinns]

It was this commit re-enabling sqlicipher that made the assertion failure start happening.

[utelle]

I will look into this.

[utelle]

It was this commit re-enabling sqlicipher that made the assertion failure start happening.

I made a quick test. IMHO the problem has nothing to do with SQLCipher. The reason must be something else. The test crashes already on setting the invalid hexkey. Other tests like the backup test still succeed.

So, something seems to go wrong on applying a key for the second time. At the moment I don't know yet, why.

[rogerbinns]

I used cvise to reduce it. The first user_version pragma is cricitcal, and the second is when the assertion fails.

import apsw
db = apsw.Connection("mcdb")
db.pragma("user_version", "")
db.pragma("hexkey", "1122")
db.pragma("user_version", "")

[utelle]

I used cvise to reduce it. The first user_version pragma is cricitcal, and the second is when the assertion fails.

import apsw
db = apsw.Connection("mcdb")
db.pragma("user_version", "")
db.pragma("hexkey", "1122")
db.pragma("user_version", "")

Thanks. That shows that the SQLCipher configuration is most likely not involved.

AFAICT SQLite deals with the assertion situation correctly later on. For example, the release version of the SQLite shell works as expected and doesn't show any misbehaviour. Of course, this is no excuse for an obvious bug, and it will be fixed. It just will take some time.

[utelle]

After some hours of debugging I think I found the reason for the assertion. Internally the wrong key was correctly detected, but it was not properly communicated to upper level functions. Actually, the error is detected later in SQLite, but in debug mode the assertion is raised first.

Commit utelle/apsw-sqlite3mc@ca146dd includes an updated amalgamation. Hopefully all tests will now run as expected.