QUERY · ISSUE

Assertion error on invalid string to compile()

openby jepleropened 2025-08-02updated 2025-08-02

bug

Port, board and/or hardware

unix port, coverage variant, x86_64 linux

MicroPython version

MicroPython v1.26.0-preview.521.g658a2e3dbd on 2025-08-02; linux [GCC 12.2.0] version

Reproduction

>>> compile("a\\\n", "", "eval")
micropython: ../../py/emitbc.c:356: mp_emit_bc_end_pass: Assertion `emit->stack_size == 0' failed.

Expected behaviour

Should throw a SyntaxError

Observed behaviour

crashes with an assertion failure

Additional Information

This crash was found by aflplusplus and minimized manually.

Code of Conduct

Yes, I agree

CANDIDATE · PULL REQUEST

py/builtinevex: Add input validation to compile()

closedby bob10042opened 2026-01-30updated 2026-01-31

Fixes #17817

Problem:
compile() accepts non-string inputs for source, filename, and mode arguments without validation, leading to assertion failures or undefined behavior.

Solution:

Validate that source, filename, and mode are all strings
Raise TypeError with descriptive message for invalid types
Fail fast before attempting to use invalid inputs

Impact:

Prevents assertion failures from invalid compile() arguments
Provides clear error messages for misuse
Matches CPython's validation behavior

Assessment

S Sonnet · medium

PR #18750 explicitly references "Fixes #17817", but there is a mismatch between the reported bug and the proposed fix. The issue reproduces with compile("a\\\n", "", "eval") — where the source IS a valid Python string. The crash occurs deep in the bytecode emitter (py/emitbc.c:356) when the compiler's stack is non-zero after processing a syntactically incomplete expression. The PR's fix adds type validation (ensuring source, filename, and mode are strings), which would not prevent the reported crash, since the reported input already passes type checks. The PR may fix a related but distinct problem (non-string inputs), not the specific assertion failure caused by a syntactically invalid but correctly-typed string.

Suggested action

Before closing #17817, verify that the merged PR actually handles `compile("a\\\n", "", "eval")` — the specific reproducer from the issue. If not, the underlying assertion in `py/emitbc.c:356` still needs a fix (likely in the compiler's error recovery path, not input validation). If the reproducer is still broken after the PR, keep #17817 open and note the remaining gap.