Fix segfault in sqlite when a future is aborted#1314
Closed
madadam wants to merge 4 commits intolaunchbadge:masterfrom
Closed
Fix segfault in sqlite when a future is aborted#1314madadam wants to merge 4 commits intolaunchbadge:masterfrom
madadam wants to merge 4 commits intolaunchbadge:masterfrom
Conversation
This guarantees that StatementHandle is never used after calling `sqlite3_finalize`. Now `sqlite3_finalize` is only called when StatementHandle is dropped.
Otherwise some tests fail to close connection.
Collaborator
|
@madadam if you're still interested in getting this merged, I have some concerns:
It's a non-trivial refactor, but I think we should actually just call I started on this in the |
Contributor
Author
|
@abonander I checked the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR attempts to fix a memory corruption that happens when a future executing a db query is interrupted (more details in #1300). It is built on top of #1186, only the last commit is new. Neither #1186, nor bb62cf7 are by themselves enough to fix this issue, but together they do seem to be.
Some notes:
The fix consist of making sure that calls to
sqlite3_resetandsqlite3_stepare never called concurrently without synchronization. The synchronization is implemented using an atomic bitflag inStatementHandle. This should be more efficient than using a mutex, however it makes the code a bit more difficult to reason about. Also the performance difference may or might not be significant. The solution only protects against concurrent use ofresetandstep, not any other functions. This should be fine as those seem to be the only two functions that might possibly be called concurrently from multiple threads. On the other hand this means that theStatementHandleAPI is strictly speaking not sound and should probably be marked asunsafe. I decided not to do it to keep the changes in this PR minimal.Closes #1300.