Bug report
PyTorch Dynamo constructs code objects with non-standard constants. This is unusual, but seems to work with the default (non-free threaded build) of CPython.
However, it crashes in the free threaded build due to a few assertions when we try to de-dupe (intern) and immortalize constants:
In compare_constants:
|
_Py_FatalErrorFormat("unexpected type in compare_constants: %s", |
|
Py_TYPE(op1)->tp_name); |
In `hash_const:
|
// This should never happen: all the constants we support have |
|
// infallible hash functions. |
|
Py_FatalError("code: hash failed"); |
We should more gracefully handle unexpected code object constants in the free threading build. I think the interning code should behave like _PyCode_ConstantKey() where unhandled objects types are treated as unequal if they are not the same instance (i.e., identity comparison for unexpected types).
cc @williamwen42
Linked PRs
Bug report
PyTorch Dynamo constructs code objects with non-standard constants. This is unusual, but seems to work with the default (non-free threaded build) of CPython.
However, it crashes in the free threaded build due to a few assertions when we try to de-dupe (intern) and immortalize constants:
In
compare_constants:cpython/Objects/codeobject.c
Lines 2671 to 2672 in 3dd3675
In `hash_const:
cpython/Objects/codeobject.c
Lines 2692 to 2694 in 3dd3675
We should more gracefully handle unexpected code object constants in the free threading build. I think the interning code should behave like
_PyCode_ConstantKey()where unhandled objects types are treated as unequal if they are not the same instance (i.e., identity comparison for unexpected types).cc @williamwen42
Linked PRs