[issue45415] Assert oparg < INSTR_OFFSET()

Steve Dower added the comment: Yes, it's been fixed. The debate about whether to test in CI with C assertions enabled or not can continue somewhere else. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tra

[issue45415] Assert oparg < INSTR_OFFSET()

Pablo Galindo Salgado added the comment: Ping. This issue is marked as release blocker, is something left here? -- ___ Python tracker ___ _

[issue45415] Assert oparg < INSTR_OFFSET()

STINNER Victor added the comment: > *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 Date: Sat Oct 9 14:17:22 2021 +0100

[issue45415] Assert oparg < INSTR_OFFSET()

STINNER Victor added the comment: 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 b

[issue45415] Assert oparg < INSTR_OFFSET()

Ken Jin added the comment: > 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 de

[issue45415] Assert oparg < INSTR_OFFSET()

Steve Dower added the comment: *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 pic

[issue45415] Assert oparg < INSTR_OFFSET()

Mark Shannon added the comment: Nothing to do with it being Windows, or computed gotos. I forgot to bump magic number again :( -- assignee: -> Mark.Shannon ___ Python tracker ___

[issue45415] Assert oparg < INSTR_OFFSET()

Steve Dower added the comment: 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? --

[issue45415] Assert oparg < INSTR_OFFSET()

Pablo Galindo Salgado added the comment: I bet you can trigger this on Linux compiling with '--without-computed-gotos'. Maybe we need a buildbot in that mode -- ___ Python tracker __

[issue45415] Assert oparg < INSTR_OFFSET()

Steve Dower added the comment: 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 th

[issue45415] Assert oparg < INSTR_OFFSET()

Steve Dower added the comment: +Pablo because of blocker. +Mark because it seems like f6eafe18c004 is probably the cause -- nosy: +Mark.Shannon, pablogsal ___ Python tracker

[issue45415] Assert oparg < INSTR_OFFSET()

New submission from Steve Dower : 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 bac