Sqlcipher_extra_shutdown() is holding Mutex during sqlcipher_atexit

SQLCipher Issues
1

Hey Experts,
Can you share any insights on the following?

Here is the stack being flagged by Appverifier as one holding lock. Working on test application that uses encrypter.dll, in which I have wrapper class over SqlCipher, this is allocated as global variable.

encrypter!winMutexInit+0x6A
encrypter!sqlite3MutexInit+0x111
encrypter!sqlite3_mutex_alloc+0x35
encrypter!sqlcipher_extra_shutdown+0x30
encrypter!sqlcipher_atexit+0x34
encrypter!<lambda_d121dba8a4adeaf3a9819e48611155df>::operator()+0x129
encrypter!__crt_seh_guarded_call::operator()<<lambda_6a47f4c8fd0152770a780fc1d70204eb>,<lambda_d121dba8a4adeaf3a9819e48611155df> &,<lambda_6aaa2265f5b6a89667e7d7630012e97a> >+0x35
encrypter!__acrt_lock_and_call<<lambda_d121dba8a4adeaf3a9819e48611155df> >+0x57
encrypter!_execute_onexit_table+0x34
encrypter!<lambda_6e4b09c48022b2350581041d5f6b0c4c>::operator()+0x95
encrypter!__crt_seh_guarded_call::operator()<<lambda_d80eeec6fff315bfe5c115232f3240e3>,<lambda_6e4b09c48022b2350581041d5f6b0c4c> &,<lambda_2358e3775559c9db80273638284d5e45> >+0x2D
encrypter!__acrt_lock_and_call<<lambda_6e4b09c48022b2350581041d5f6b0c4c> >+0x57
encrypter!common_exit+0x70
encrypter!_cexit+0x13
encrypter!__scrt_dllmain_uninitialize_c+0x2A
encrypter!dllmain_crt_process_detach+0x4D
encrypter!dllmain_crt_dispatch+0x67
encrypter!dllmain_dispatch+0xFF
encrypter!_DllMainCRTStartup+0x32
verifier!AVrfpStandardDllEntryPointRoutine+0xE9

2

Hello @Deb - In this case, sqlcipher_extra_shutdown is obtaining a lock so it can proceed with cleanup of sqlcipher library internals. A mutex is used to ensure that access is properly synchronized. We have not observed problems with this in the past. Can you please explain the specific problem you are facing in more detail?

3

Problem:
With SqlCipher 4.7.0, application verifier flags my application, saying it is holding lock inside global variable.
Same code works good with older version 4.6.1 but I do not want to use it since it is older.

4

Can the following be fix for the problem?

After below line, calling sqlite3_mutex_free(mutex);

In other words can code be as below?

cleanup:
sqlcipher_init = 0;
sqlcipher_init_error = SQLITE_ERROR;
sqlcipher_shutdown = 1;
if(mutex) {
sqlite3_mutex_leave(mutex);
[[sqlite3_mutex_free(mutex);]] => This being the fix ?
}

5

@Deb No, I don’t think that is the proper solution. The mutex in question is an internal static mutex and should not be freed like that.

We’re still looking into this. Can you provide a small standalone project that reproduces this problem so we can troubleshoot further? If so, please email it to support@zetetic.net. That is the quickest way to assist and get resolution.