Skip to content

Conversation

@picnixz
Copy link
Member

@picnixz picnixz commented Dec 27, 2025

FTR, the reason why execute is 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.

@picnixz picnixz added needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes labels Dec 27, 2025
@picnixz picnixz changed the title gh-143198: fix SIGSEGV in sqlite3.execute[many] with re-entrant parameter iterator gh-143198: fix SIGSEGV in sqlite3.execute[many] with concurrent mutations Dec 27, 2025
@picnixz picnixz marked this pull request as draft December 27, 2025 15:19
@picnixz picnixz changed the title gh-143198: fix SIGSEGV in sqlite3.execute[many] with concurrent mutations gh-143198: fix SIGSEGV in sqlite3.executemany with concurrent mutations Dec 27, 2025
@picnixz picnixz marked this pull request as ready for review December 27, 2025 16:42
}
// 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)) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member Author

@picnixz picnixz Dec 27, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting merge needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants