We have updated SQLCipher from 4.5.7 to 4.6.1 built for Windows and Linux and now run into the following problem:
We run small mocha tests for our application and its database in a gitlab pipeline on a Windows Build Server and a dockerized Linux system. These runners should have enough memory to accomodate the tests without problems. While the test succeed, the runners spam the following logs:
ERROR MEMORY sqlcipher_mlock: VirtualLock() returned 0 LastError=1453 // Windows
and
ERROR MEMORY sqlcipher_mlock: mlock() returned -1 errno=12 // Ubuntu
When running the tests locally (piping the SQLCipher output), these errors do not appear. They also do not appear in the pipeline when using version 4.5.7 (we turnt on the log manually).
We were able to surpress the error on the Ubuntu runner by giving Docker privileged capabilities. On Windows, however, we are not able to surpress it.
We check the updates in the source code but could not see any change that could trigger such a change in the output when allocating the memory using mlock or VirtualLock. Do you have any hints as to why they behavior could have changed and what we could do to circumvent it without giving additional capabilities to the runners?
Hello @albertgi - thanks for getting in touch about this.
The additional log output you are now seeing is likely due to changes in SQLCipher’s default logging configuration. In previous versions of SQLCipher log output was disabled by default. This changed starting with SQLCipher 4.6.0, where ERROR and WARN log message are emitted to a default log target.
The underlying issue with locking has to do with SQLCipher being unable to memory lock a page, either due to an exceeded quota or permission issue. This is not a blocking error for SQLCipher, it can continue to operate without locking pages. As a result we will likely reduce that from an ERROR log level to WARN in an upcoming release.
These types or log messages may be more frequent in memory constrained environments, when running under restricted privileges, repeatedly opening and closing connections (including attached databases), all of which may be more likely in CI/CD pipelines.
It is unusual that you would see a difference between 4.5.7 with logging enabled, and 4.6.1. How were you enabling logging in 4.5.7?
If you would like to suppress the log messages in your pipeline you could consider adjusting the log sources to exclude MEMORY, via the following PRAGMA:
https://www.zetetic.net/sqlcipher/sqlcipher-api/#cipher_log_source
Finally, I noticed that your organization is a commercial licensee, so if you would prefer to share information via private support, please contact us at support@zetetic.net.
Hi, thanks a lot for the reply and the explanation. I saw that in version 4.5.7, the logs also occur (I did not set the log level high enough when testing).
We will see how we deal with these logs. We believe that considering the circumstances, downgrading the log from error to warn in a future version seems to be adecuate.