Python/flowgraph.c:528: _Bool all_exits_have_lineno(basicblock *): Assertion `0' failed

[alex]

Crash report

What happened?

Reproducing code:

class i:
 if i:d<2<[super for()in e]

~/p/cpython ❯❯❯ ./python.exe -c '
                class i:
                 if i:d<2<[super for()in e]'
Assertion failed: (0), function all_exits_have_lineno, file flowgraph.c, line 528.

Crash:

fuzz_pycompile: Python/flowgraph.c:528: _Bool all_exits_have_lineno(basicblock *): Assertion `0' failed.
--
  | AddressSanitizer:DEADLYSIGNAL
  | =================================================================
  | ==27322==ERROR: AddressSanitizer: ABRT on unknown address 0x053900006aba (pc 0x7b9e312b000b bp 0x7b9e31425588 sp 0x7ffddbefe650 T0)
  | SCARINESS: 10 (signal)
  | #0 0x7b9e312b000b in raise /build/glibc-SzIz7B/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
  | #1 0x7b9e3128f858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
  | #2 0x7b9e3128f728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
  | #3 0x7b9e312a0fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
  | #4 0x86784f in all_exits_have_lineno cpython3/Python/flowgraph.c:528:21
  | #5 0x86784f in _PyCfg_OptimizeCodeUnit cpython3/Python/flowgraph.c:2474:5
  | #6 0x7e624f in optimize_and_assemble_code_unit cpython3/Python/compile.c:7583:9
  | #7 0x7e624f in optimize_and_assemble cpython3/Python/compile.c:7625:12
  | #8 0x814aeb in compiler_class_body cpython3/Python/compile.c:2545:24
  | #9 0x7f248e in compiler_class cpython3/Python/compile.c:2607:9
  | #10 0x7f248e in compiler_visit_stmt cpython3/Python/compile.c:3978:16
  | #11 0x7e8973 in compiler_body cpython3/Python/compile.c:1731:9
  | #12 0x7e276e in compiler_codegen cpython3/Python/compile.c:1747:13
  | #13 0x7dff40 in compiler_mod cpython3/Python/compile.c:1775:9
  | #14 0x7dff40 in _PyAST_Compile cpython3/Python/compile.c:555:24
  | #15 0x93b2e3 in Py_CompileStringObject cpython3/Python/pythonrun.c:1452:10
  | #16 0x93b3d4 in Py_CompileStringExFlags cpython3/Python/pythonrun.c:1465:10
  | #17 0x587501 in fuzz_pycompile cpython3/Modules/_xxtestfuzz/fuzzer.c:550:24
  | #18 0x587501 in _run_fuzz cpython3/Modules/_xxtestfuzz/fuzzer.c:563:14
  | #19 0x587501 in LLVMFuzzerTestOneInput cpython3/Modules/_xxtestfuzz/fuzzer.c:704:11
  | #20 0x458923 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
  | #21 0x444082 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
  | #22 0x44992c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
  | #23 0x472e62 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
  | #24 0x7b9e31291082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  | #25 0x43a24d in _start

cc: @iritkatriel

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

No response

Linked PRs

• gh-114828: Fix __class__ in class-scope inlined comprehensions #115139
• [3.12] gh-114828: Fix __class__ in class-scope inlined comprehensions (GH-115139) #115140
• gh-114828: parenthesize non-atomic macro definitions in pycore_symtable.h #115143
• [3.12] gh-114828: parenthesize non-atomic macro definitions in pycore_symtable.h (GH-115143) #115149

[iritkatriel]

This simplified input compiles in 3.11 but now doesn't:

e = []

class i:
    [super for()in e]

CC @carljm

Gives:

SystemError: PySTGetScope(name='__class') failed: unknown scope in unit <module> (140429878239776); symbols: {'e': 4098, 'i': 4098}; locals: {}; globals: {'e': 0}

[carljm]

@iritkatriel The fix for the simplified case that results in the "unknown scope" crash is merged and backported. I'm not sure if there are other remaining issues here that can lead to the "all exits have lineno" assertion error mentioned in the title, so I'll leave this open, but remove my assignment. Thanks for the ping!

[alex]

The fuzzer is pretty good at finding them, so I think we can close this and I'll be back with a new bug in a day or two if it finds another path to that assert.

[iritkatriel]

@alex The issue with super was kind of accidentally discovered here - if it wasn't for the line number assertion, I think the fuzzer would not have found it, right?

I'm guessing the fuzzer discards any code that doesn't compile, but here we had code that should have compiled (it did in 3.11).

[alex]

Yes, it currently ignores any exceptions: https://github.com/python/cpython/blob/main/Modules/_xxtestfuzz/fuzzer.c#L550-L553

One thing we could do is make it crash on SystemError, in which case it would have caught the underlying bug.

Is there ever any non-bug reason for compile() to raise a systemerror?

[iritkatriel]

Is there ever any non-bug reason for compile() to raise a systemerror?

I doubt it. Sound like a good idea to treat SystemError as a problem.

[alex]

Great. Unless you're interested in working on it, I'll add it to my TODO list to add that check.