encodings.search_function is triggering this assertion at Python/ceval.c#L4055:

       TARGET(JUMP_ABSOLUTE) {
            PREDICTED(JUMP_ABSOLUTE);
            assert(oparg < INSTR_OFFSET());    <<<

It seems to be saying that absolute jumps should only go backwards?

The assertion is triggering reliably in a Windows debug build (including as part of the build process, which means we can't release right now). I don't see anything Windows-specific here though, so I assume it's core and may just be a codepath in encodings that Linux doesn't use?

+Pablo because of blocker.

+Mark because it seems like f6eafe18c004 is probably the cause

Also +Victor, because I think we should switch back to debug builds in CI in order to catch failed assertions before they get merged.

Since you're the most strongly against this, I wanted to give you a chance to argue against it (or suggest a better approach than just switching to the debug build).

I bet you can trigger this on Linux compiling with '--without-computed-gotos'.

Maybe we need a buildbot in that mode

I can't get it to go with that option (with or without -DDEBUG, which I *think* is needed to get assert to work?), and I also don't see anything obvious in the changeset I linked. So I guess there's some other assumption that isn't holding?

Nothing to do with it being Windows, or computed gotos.
I forgot to bump magic number again :(

*facepalm* on myself, for not even thinking of that. Indeed, clearing all my .pyc files fixes it.

I think I got distracted by the error coming from one of the newly frozen modules, except because we're in tree it shouldn't be using the frozen one, so it is picking up the cached file instead.

> I think we should switch back to debug builds in CI in order to catch failed assertions before they get merged.

I'm not Victor, but +1. I've been bitten by release builds not catching things, see issue44348 for example where I advocated for switching back to debug builds for Windows.

FWIW, the macOS and Ubuntu CI use debug builds too. So I don't see why Windows is special.

Steve:
> Also +Victor, because I think we should switch back to debug builds in CI in order to catch failed assertions before they get merged.

Ken Jin:
> So I don't see why Windows is special.

The Python test suite is way slower on Windows when Python is built in debug mode: 19 min 41 sec (debug) instead of 12 min 19 sec (release) on Windows x64: 1.6x slower.

* https://bugs.python.org/issue45115#msg401141
* https://github.com/python/cpython/pull/28181

I would prefer to not make our workflow slower. IMO it's ok to miss a few bugs in pre-commit checks, and only catch them on Windows debug buildbots. In my experience, it happens less than once per months. It's more like 2 or 3 times per year.

> *facepalm* on myself, for not even thinking of that. Indeed, clearing all my .pyc files fixes it.

This issue has been fixed, no? Can it be closed?

commit 5e173f5db17cbb2e3f2139a3c5ccb6b81ac59785
Author: Mark Shannon <mark@hotpy.org>
Date:   Sat Oct 9 14:17:22 2021 +0100

    Bump MAGIC_NUMBER to reflect change in JUMP_ABSOLUTE semantics. (GH-28829)

Ping. This issue is marked as release blocker, is something left here?

Yes, it's been fixed.

The debate about whether to test in CI with C assertions enabled or not can continue somewhere else.