Fix segfault in sqlite when a future is aborted #1314
Closed
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_reset
andsqlite3_step
are 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 ofreset
andstep
, 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 theStatementHandle
API 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.