-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Crash in Python/assemble.c:301: write_location_info_entry: Assertion `column >= -1' failed. #130775
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
Comments
I'm tempted to raise when constructing artificial AST nodes, but I'm not sure I'm not sure whether it could break code. Maybe people are using fake AST nodes with bad location values just for their own needs, like for a sentinel value. OTOH, checking the consistency of all AST nodes in @JelleZijlstra any recommendation here? |
Is this causing a problem in practice, or just when fuzzing? |
In practice, it's causing an assertion failure and a crash. So yes, it could be a problem in practice for static analysis tools that may perhaps incorrectly determine some values. In addition, it may cause issues since without the assertion, the location data would be incorrect and we could end up with incorrect bytecode. |
Or maybe convert if (column < -1 || end_column < -1) {
const char *msg = column < -1 ? "column" : "end_column";
int value = column < -1 ? column : end_column;
PyErr_Format(PyExc_ValueError,
"invalid %s value: %d",
msg, value);
return ERROR;
} Will produce: » ./python.exe
Python 3.14.0a5+ (heads/main-dirty:8f11af45de6, Mar 3 2025, 14:19:56) [Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
...
... tree = ast.Module(body=[
... ast.Import(names=[ast.alias(name='traceback', lineno=0, col_offset=0)], lineno=0, \
col_offset=-2)
... ], type_ignores=[])
...
... compile(tree, "<string>", "exec")
...
Traceback (most recent call last):
File "<python-input-0>", line 7, in <module>
compile(tree, "<string>", "exec")
~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid column value: -2 |
Yes, but my question was: should we do it when we construct the AST nodes or should we do it in assemble.c? |
In my opinion, it is better to do in |
I can think of some advantages of doing in either module:
|
I think it's better to do it in the assembler. There are other things you can do with ASTs than compiling, and for those it may make sense to use invalid column values. For example, if you're constructing an AST and then stringifying it with something like |
|
I now fully sure that adding this to >>> import ast
...
... tree = ast.Module(body=[
... ast.Import(names=[ast.alias(name='', lineno=0, col_offset=0)], lineno=0, col_offset=-1)
... ], type_ignores=[])
...
>>> eval(compile(tree, "<string>", "exec"))
Traceback (most recent call last):
File "<python-input-10>", line 1, in <module>
eval(compile(tree, "<string>", "exec"))
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<string>", line 0, in <module>
ValueError: Empty module name I have a PR with the change above. |
Sorry, I was not really correct with my phrase:
We do validate some values, for example, locations: Lines 29 to 48 in b3c18bf
So, it might be a good idea to fix this macro. It does not make any sense to use |
Co-authored-by: Victor Stinner <[email protected]>
…30795) (cherry picked from commit bc5233b) Co-authored-by: sobolevn <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
…30795) (cherry picked from commit bc5233b) Co-authored-by: sobolevn <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
) (cherry picked from commit bc5233b) Co-authored-by: sobolevn <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
Co-authored-by: Victor Stinner <[email protected]>
Crash report
What happened?
Bug Description
This is a bug that only affects DEBUG builds.
The reproducer is as follow:
This code fails with:
backtrace
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.14.0a4+ (heads/main-dirty:75f59bb6293, Jan 23 2025, 22:33:08) [GCC 13.3.0]
Linked PRs
ast
#130795ast
(GH-130795) #132243ast
(GH-130795) #132260The text was updated successfully, but these errors were encountered: