Assertion failure at Objects/codeobject.c:1199: 'void advance_with_locations(PyCodeAddressRange *, int *, int *, int *): Assertion `bounds->opaque.lo_next <= bounds->opaque.limit .. ' failed`

[YuanchengJiang]

Crash report

What happened?

import dis

def template(): pass

# Construct bytecode: RESUME(0), LOAD_CONST(0), RAISE_VARARGS(1)
# 3 instructions, 6 bytes total.
op_resume = dis.opmap.get('RESUME', dis.opmap.get('NOP', 9))
op_load = dis.opmap.get('LOAD_COMMON_CONSTANT', dis.opmap.get('LOAD_CONST', 100))
op_raise = dis.opmap.get('RAISE_VARARGS', 89)

code_bytes = bytes([op_resume, 0, op_load, 0, op_raise, 1])

# The malformed linetable (derived from fusion=0 in original)
# This is likely too short to cover the bytecode instructions provided above.
linetable = bytes([0, 0])

# Replace code object internals
new_code = template.__code__.replace(
    co_code=code_bytes,
    co_linetable=linetable,
    co_firstlineno=42,
    co_stacksize=1
)

# Trigger: Iterating positions forces CPython to parse the malformed linetable
list(new_code.co_positions())

python: ../Objects/codeobject.c:1199: void advance_with_locations(PyCodeAddressRange *, int *, int *, int *): Assertion `bounds->opaque.lo_next <= bounds->opaque.limit && (bounds->ar_line == -1 || bounds->ar_line == bounds->opaque.computed_line) && (bounds->opaque.lo_next == bounds->opaque.limit || (*bounds->opaque.lo_next) & 128)' failed.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

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

No response

[YuanchengJiang]

This seems to manipulate the code object illegally? :|

[picnixz]

I think so =/ I still have #126119 but now that i think about it should probably fall within the realm of "don't mess with code objects".

EDIT: The other issue is actually not just messing up with code objects. It's a real (possible) issue albeit very very hard to come up (absurdly large stack is nonsensical).

[picnixz]

Ok, since I consistently closed other issues about code.replace, let's close this one as well. At some point, we'll decide whether or not messing up with line tables is legitimate or not.