-
-
Notifications
You must be signed in to change notification settings - Fork 33.8k
gh-143198: fix SIGSEGV in sqlite3.executemany with concurrent mutations
#143210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…nt parameter iterator
Misc/NEWS.d/next/Library/2025-12-27-10-36-18.gh-issue-143198.DdIHyC.rst
Outdated
Show resolved
Hide resolved
sqlite3.execute[many] with re-entrant parameter iteratorsqlite3.execute[many] with concurrent mutations
sqlite3.execute[many] with concurrent mutationssqlite3.executemany with concurrent mutations
| } | ||
| // PyIter_Next() may have a side-effect on the connection's state. | ||
| // See: https://github.com/python/cpython/issues/143198. | ||
| if (!pysqlite_check_connection(self->connection)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| if (!pysqlite_check_connection(self->connection)) { | |
| if (multiple && !pysqlite_check_connection(self->connection)) { |
Strictly speaking, this check is redundant when dealing with mutliple = 0 because parameters_iter is a true list_iterator that is safely constructed and parameters may be an evil one. With multiple = 1, we need to check this at every iteration as parameters_iter may come from user-defined code.
| if (!parameters) { | ||
| break; | ||
| } | ||
| // PyIter_Next() may have a side-effect on the connection's state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: if parameters is NULL and we have an active exception, we break the loop. It should only happen when we are having a custom iterator, that is, multiple = 1. As such, we wouldn't branch into the if (!multiple) and we wouldn't call PyLong_FromLongLong.
However, I'll add tomorrow some assertions because it's not entirely clear from the code alone.
FTR, the reason why
executeis actually not affected is that the iterator we are taking is built from a list we create ourselves so it's not possible to have "bad" side effects._sqlitecursor cache via re-entrant parameter iterator #143198