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

Python/flowgraph.c:701: basicblock *push_except_block(struct _PyCfgExceptStack *, cfg_instr *): Assertion `stack->depth <= CO_MAXBLOCKS' failed #116767

Closed
alex opened this issue Mar 13, 2024 · 10 comments · Fixed by #118348
Assignees
Labels
3.12 bugs and security fixes 3.13 bugs and security fixes deferred-blocker type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@alex
Copy link
Member

alex commented Mar 13, 2024

Crash report

What happened?

Minimal reproducer

async def t():
 async with h,t,t,o,f,y,o,t,r,o,f,t,f,r,t,m,r,o,t,l:n
~/p/cpython ❯❯❯ ./python.exe -c 'async def t():
                 async with h,t,t,o,f,y,o,t,r,o,f,t,f,r,t,m,r,o,t,l:n'
Assertion failed: (stack->depth <= CO_MAXBLOCKS), function push_except_block, file flowgraph.c, line 707.
fish: Job 1, './python.exe -c 'async def t():' terminated by signal  async with h,t,t,o,f,y,o,t,r,o… (SIGABRT)
fish: Job Abort, '' terminated by signal  ()

Full ASAN:


fuzz_pycompile: Python/flowgraph.c:701: basicblock *push_except_block(struct _PyCfgExceptStack *, cfg_instr *): Assertion `stack->depth <= CO_MAXBLOCKS' failed.
--
  | AddressSanitizer:DEADLYSIGNAL
  | =================================================================
  | ==16858==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000041da (pc 0x7a22fe4c600b bp 0x7a22fe63b588 sp 0x7ffe3dd3ff40 T0)
  | SCARINESS: 10 (signal)
  | #0 0x7a22fe4c600b in raise /build/glibc-SzIz7B/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
  | #1 0x7a22fe4a5858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
  | #2 0x7a22fe4a5728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
  | #3 0x7a22fe4b6fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
  | #4 0x8f5084 in push_except_block cpython3/Python/flowgraph.c:701:5
  | #5 0x8f5084 in label_exception_targets cpython3/Python/flowgraph.c:896:27
  | #6 0x8e5db6 in _PyCfg_OptimizeCodeUnit cpython3/Python/flowgraph.c:2490:5
  | #7 0x8702e3 in optimize_and_assemble_code_unit cpython3/Python/compile.c:7598:9
  | #8 0x8702e3 in optimize_and_assemble cpython3/Python/compile.c:7640:12
  | #9 0x8948d7 in compiler_function_body cpython3/Python/compile.c:2309:24
  | #10 0x8948d7 in compiler_function cpython3/Python/compile.c:2410:9
  | #11 0x8770af in compiler_visit_stmt cpython3/Python/compile.c:0
  | #12 0x874f14 in compiler_body cpython3/Python/compile.c:1729:9
  | #13 0x86c2fc in compiler_codegen cpython3/Python/compile.c:1740:13
  | #14 0x869346 in compiler_mod cpython3/Python/compile.c:1781:9
  | #15 0x869346 in _PyAST_Compile cpython3/Python/compile.c:555:24
  | #16 0x9f3d07 in Py_CompileStringObject cpython3/Python/pythonrun.c:1449:10
  | #17 0x9f3dfc in Py_CompileStringExFlags cpython3/Python/pythonrun.c:1462:10
  | #18 0x4f8fcc in fuzz_pycompile cpython3/Modules/_xxtestfuzz/fuzzer.c:551:24
  | #19 0x4f8fcc in _run_fuzz cpython3/Modules/_xxtestfuzz/fuzzer.c:570:14
  | #20 0x4f8fcc in LLVMFuzzerTestOneInput cpython3/Modules/_xxtestfuzz/fuzzer.c:711:11
  | #21 0x4f99ed in ExecuteFilesOnyByOne /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:255:7
  | #22 0x4f97e8 in LLVMFuzzerRunDriver /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:0
  | #23 0x4f939d in main /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:311:10
  | #24 0x7a22fe4a7082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  | #25 0x43a0ad in _start

cc: @iritkatriel

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

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

No response

Linked PRs

@alex alex added the type-crash A hard crash of the interpreter, possibly with a core dump label Mar 13, 2024
@iritkatriel iritkatriel self-assigned this Mar 13, 2024
@alex
Copy link
Member Author

alex commented Mar 13, 2024

c31943a is the commit that OSS-Fuzz attributes this crash to (though obviously that just made it an assertion failure, instead of something else)

@alex
Copy link
Member Author

alex commented Mar 13, 2024

@iritkatriel thanks for jumping on all of these

@alex alex added release-blocker 3.13 bugs and security fixes labels Mar 31, 2024
@encukou
Copy link
Member

encukou commented Apr 4, 2024

@iritkatriel do you need help with this bug?

@iritkatriel
Copy link
Member

It's not complicated, I'm just prioritising things I need to get in before feature freeze.

@encukou
Copy link
Member

encukou commented Apr 8, 2024

This is a release blocker. Will you prioritize it in time for the release or should I look at it instead?

@encukou encukou added the 3.12 bugs and security fixes label Apr 8, 2024
@iritkatriel
Copy link
Member

It shouldn't be a release blocker. (1) It is an unrealistic edge case discovered by the fuzzer. (2) it is not new to 3.13.

@alex
Copy link
Member Author

alex commented Apr 8, 2024

The reason I marked it as a blocker is that the RMs had previously marked all the fuzzer identified crashes as blockers.

@iritkatriel
Copy link
Member

I'll make it a deferred blocker so we won't forget to fix it for 3.13 release.

@iritkatriel
Copy link
Member

@encukou See #118348.

encukou pushed a commit that referenced this issue May 1, 2024
…18348)

Account for `add_stopiteration_handler` pushing a block for `async with`.
To allow generator functions that previously almost hit the `CO_MAXBLOCKS`
limit by nesting non-async blocks, the limit is increased by 1.
This increase allows one more block in non-generator functions.
@encukou encukou reopened this May 1, 2024
iritkatriel added a commit to iritkatriel/cpython that referenced this issue May 1, 2024
…pythonGH-118348)

Account for `add_stopiteration_handler` pushing a block for `async with`.
To allow generator functions that previously almost hit the `CO_MAXBLOCKS`
limit by nesting non-async blocks, the limit is increased by 1.
This increase allows one more block in non-generator functions.

(cherry picked from commit c1bf487)
iritkatriel added a commit that referenced this issue May 1, 2024
GH-118348) (#118477)

gh-116767: fix crash on 'async with' with many context managers (GH-118348)

Account for `add_stopiteration_handler` pushing a block for `async with`.
To allow generator functions that previously almost hit the `CO_MAXBLOCKS`
limit by nesting non-async blocks, the limit is increased by 1.
This increase allows one more block in non-generator functions.

(cherry picked from commit c1bf487)
@encukou
Copy link
Member

encukou commented May 2, 2024

Thank you for getting to this!

@encukou encukou closed this as completed May 2, 2024
SonicField pushed a commit to SonicField/cpython that referenced this issue May 8, 2024
…pythonGH-118348)

Account for `add_stopiteration_handler` pushing a block for `async with`.
To allow generator functions that previously almost hit the `CO_MAXBLOCKS`
limit by nesting non-async blocks, the limit is increased by 1.
This increase allows one more block in non-generator functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.12 bugs and security fixes 3.13 bugs and security fixes deferred-blocker type-crash A hard crash of the interpreter, possibly with a core dump
Projects
Development

Successfully merging a pull request may close this issue.

3 participants