Skip to content

Conversation

@sobolevn
Copy link
Member

@sobolevn sobolevn commented Jan 10, 2026

I also added one more test case for a second possible crash in the same function.

return PyUnicodeWriter_WriteASCII(writer, "None", 4);
}

Py_INCREF(p); // gh-143635
Copy link
Member

Choose a reason for hiding this comment

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

This sort of feels like the wrong place, shouldn't callers of the function ensure they have a reference to p that remains valid?

Copy link
Member

Choose a reason for hiding this comment

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

I think so and we should just say that the function takes a strong reference (the function is not documented but it would be good to indicate this).

That means changing some PyList_GET_ITEM/PyTuple_GET_ITEM and adding some Py_INCREF for non-sequences.

Copy link
Member Author

@sobolevn sobolevn Jan 11, 2026

Choose a reason for hiding this comment

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

Hm, I am not quite sure about it. Technically, we don't need a strong reference in regular cases, it is only needed for strange self-destructing ones.

We have multiple places where we just use Py_INCREF / Py_DECREF on a object before calling some python callbacks with it. Changing this function to require a strong refenrence will require quite a lot of refactoring for a very niche thing (and might be a breaking change for anyone using this function, even though it is not documented).

Let's say we want to refactor this place:

if (_Py_typing_type_repr(writer, alias->origin) < 0) {
goto error;
}

It would be:

Py_INCREF(alias->origin);
if (_Py_typing_type_repr(writer, alias->origin) < 0) {
     Py_DECREF(alias->origin);
     goto error;
}
Py_DECREF(alias->origin);

This does not seem like a good API to me :/

What are the potential limitations of the current approach?

Copy link
Member

Choose a reason for hiding this comment

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

Changing this function to require a strong refenrence will require quite a lot of refactoring for a very niche thing (and might be a breaking change for anyone using this function, even though it is not documented).

It's not exported as part of the public API so I'm not sure it's available by "others" (it's only an extern symbol in the internal API). Since it's internal we can also keep your change as it reduces the diff (I didn't think there would be that many places though)

@JelleZijlstra
Copy link
Member

This needs NEWS since it fixes a user-visible crash.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants