Skip to content

Conversation

@mpage
Copy link
Contributor

@mpage mpage commented May 31, 2025

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

  • FORMAT_SIMPLE leaves its operand on the stack if its a unicode object.
  • GET_YIELD_FROM_ITER leaves its operand on the stack if its a coroutine or generator object.
  • END_SEND leaves the TOS in place.
  • SET_FUNCTION_ATTRIBUTE leaves the TOS in place.
  • PUSH_EXC_INFO leaves the TOS in place.
  • LOAD_SPECIAL may leave the TOS (self) in place.

mpage added 7 commits May 30, 2025 10:09
`FORMAT_SIMPLE` leaves its operand on the stack if its a unicode object.
Since we cannot determine that at analysis (compile) time, treat it
conservatively and assume it always leaves the operand on the stack.
It leaves the function on the stack
`GET_YIELD_FROM_ITER` doesn't consume its operand if its a coroutine
or generator, so treat it conservatively.

`END_SEND` leaves the TOS.
It leaves the TOS in place.
Load special may leave `self` on TOS. Treat it conservatively and
assume it always does.
@mgorny
Copy link
Contributor

mgorny commented May 31, 2025

I suppose this means Python 3.14 is going to see an ABI breakage too, is that correct?

@mpage
Copy link
Contributor Author

mpage commented May 31, 2025

I suppose this means Python 3.14 is going to see an ABI breakage too, is that correct?

I don’t think so. This doesn’t change the binary layout of anything. What about this would cause an ABI breakage?

@thesamesam
Copy link
Contributor

It changed PYC_MAGIC_NUMBER (which is fine if it can't be avoided, it's just a pain if it can be).

@mpage
Copy link
Contributor Author

mpage commented May 31, 2025

It changed PYC_MAGIC_NUMBER (which is fine if it can't be avoided, it's just a pain if it can be).

I think I’m missing something. The magic number changes with every minor release. Since we haven’t released 3.14 yet, bumping the magic number shouldn’t cause any additional pain beyond what’s felt with a normal release.

@mgorny
Copy link
Contributor

mgorny commented May 31, 2025

A few Linux distributions have already engaged in a lot of Python 3.14 testing (at least Fedora and Gentoo I'm aware of), and these systems will be affected by the magic number change.

@hroncok
Copy link
Contributor

hroncok commented May 31, 2025

In Fedora, we can deal with the chnage of the magic number in b3. But the sooner it happens the better.

@mpage mpage marked this pull request as ready for review June 3, 2025 16:07
@mpage mpage requested review from Yhg1s and colesbury June 3, 2025 16:07
@mpage mpage merged commit 6b77af2 into python:main Jun 4, 2025
39 checks passed
@mpage mpage added the needs backport to 3.14 bugs and security fixes label Jun 4, 2025
@miss-islington-app
Copy link

Thanks @mpage for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

@miss-islington-app
Copy link

Sorry, @mpage, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 6b77af257c25d31f1f137e477cb23e63692ddf29 3.14

mpage added a commit to mpage/cpython that referenced this pull request Jun 5, 2025
…FAST` (python#134958)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

(cherry picked from commit 6b77af2)
@bedevere-app
Copy link

bedevere-app bot commented Jun 5, 2025

GH-135187 is a backport of this pull request to the 3.14 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.14 bugs and security fixes label Jun 5, 2025
mpage added a commit that referenced this pull request Jun 5, 2025
…_FAST` (#134958) (#135187)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

(cherry picked from commit 6b77af2)
Pranjal095 pushed a commit to Pranjal095/cpython that referenced this pull request Jul 12, 2025
…FAST` (python#134958)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.
taegyunkim pushed a commit to taegyunkim/cpython that referenced this pull request Aug 4, 2025
…FAST` (python#134958)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.
Agent-Hellboy pushed a commit to Agent-Hellboy/cpython that referenced this pull request Aug 19, 2025
…FAST` (python#134958)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants