Memory leak after VACUUM

[synopse]

From my preliminary tests, performing a VACUUM makes a memory leak of the codec instance (65xxx bytes). With no VACUUM (i.e. regular INSERT/UPDATE/SELECT), no memory leak.
I guess there is a missing sqlite3mcCodecFree() call somewhere...
Perhaps the ATTACH statement executed during VACCUM doesn't work as expected.

[utelle]

Thanks for reporting the issue. I will look into it.

VACUUM creates a temporary new database file. If the main database is encrypted, a copy of the main codec will be made. Maybe this copy is not freed as it should. I will have to check what's going on.

[synopse]

If I comment the last sqlite3mcCodeAttach() in sqlite3mcHandleAttachKey (case SQLITE_NULL - which is the case for the ATTACH temp db made during VACUUM), I don't have any leak, and the file is still encrypted after the vacuum... weird...

[utelle]

The VACUUM command attaches a temporary database without using a file name. As a consequence there is no SQLite file handle to which the codec could be attached.

The current implementation does not detect this situation correctly: a codec is allocated and initialized, but not freed.

Commenting the call to sqlite3mcCodeAttach as you did solves the problem only for this special case, but not for the general case.

I will provide a fix within the next few days.

[utelle]

Commit 2794168 should fix the issue.

If no SQLite file handle can be found in function sqlite3mcSetCodec the codec is freed.

[utelle]

Closing... reopen if necessary.