Skip to content
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

Invalid Assert in PyState_FindModule() #119560

Closed
ericsnowcurrently opened this issue May 25, 2024 · 1 comment
Closed

Invalid Assert in PyState_FindModule() #119560

ericsnowcurrently opened this issue May 25, 2024 · 1 comment
Assignees
Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@ericsnowcurrently
Copy link
Member

ericsnowcurrently commented May 25, 2024

Crash report

Bug description:

gh-118532 added an assert that is erroneously triggers if PyState_FindModule() is called before the provided module def has been initialized. The assert should be removed. (Python/import.c, line 460)

See ultrajson/ultrajson#629.

CPython versions tested on:

3.13, CPython main branch

Operating systems tested on:

No response

Linked PRs

@ericsnowcurrently ericsnowcurrently added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump 3.13 bugs and security fixes 3.14 new features, bugs and security fixes labels May 25, 2024
@ericsnowcurrently ericsnowcurrently self-assigned this May 25, 2024
ericsnowcurrently added a commit that referenced this issue May 25, 2024
The assertion was added in gh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def.  I've added a test to make sure we don't make that assumption again.
@mgorny
Copy link
Contributor

mgorny commented May 26, 2024

Thanks. I can confirm that after applying this on top of 3.13.0b1, ujson passes all tests.

miss-islington pushed a commit to miss-islington/cpython that referenced this issue May 27, 2024
…ongh-119561)

The assertion was added in pythongh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def.  I've added a test to make sure we don't make that assumption again.
(cherry picked from commit 0c5ebe1)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
ericsnowcurrently added a commit that referenced this issue May 27, 2024
…119561) (gh-119632)

The assertion was added in gh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def.  I've added a test to make sure we don't make that assumption again.

(cherry picked from commit 0c5ebe1)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
estyxx pushed a commit to estyxx/cpython that referenced this issue Jul 17, 2024
…ongh-119561)

The assertion was added in pythongh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def.  I've added a test to make sure we don't make that assumption again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

2 participants