Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-117139: Fix a few wrong steals in bytecodes.c #121127

Merged
merged 1 commit into from
Jun 28, 2024

Conversation

Fidget-Spinner
Copy link
Member

@Fidget-Spinner Fidget-Spinner commented Jun 28, 2024

I actually caught these using a tool I built following the stackref semantics here https://github.com/faster-cpython/ideas/blob/kenjin/stackref-semantics/3.14/stackref_semantics.md.

I'll send the PR for the tool in a separate PR.

These bugs were quite hard to notice, I will explain each one in comments below.

@@ -673,7 +673,7 @@ dummy_func(
err = 1;
}
else {
err = PyObject_SetItem(PyStackRef_AsPyObjectBorrow(container), slice, PyStackRef_AsPyObjectSteal(v));
err = PyObject_SetItem(PyStackRef_AsPyObjectBorrow(container), slice, PyStackRef_AsPyObjectBorrow(v));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PyObject_SetItem and the entire family actually takes borrowed references to the container and item. So this steal is wrong, it should be borrow.

This was caught when the PyStackRef_CLOSE(v) below tried to close an already invalid stackref (it was made invalid by the steal).

@@ -789,7 +789,7 @@ dummy_func(

inst(SET_ADD, (set, unused[oparg-1], v -- set, unused[oparg-1])) {
int err = PySet_Add(PyStackRef_AsPyObjectBorrow(set),
PyStackRef_AsPyObjectSteal(v));
PyStackRef_AsPyObjectBorrow(v));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for PySet_Add

@@ -1450,7 +1450,7 @@ dummy_func(
op(_STORE_ATTR, (v, owner --)) {
PyObject *name = GETITEM(FRAME_CO_NAMES, oparg);
int err = PyObject_SetAttr(PyStackRef_AsPyObjectBorrow(owner),
name, PyStackRef_AsPyObjectSteal(v));
name, PyStackRef_AsPyObjectBorrow(v));
Copy link
Member Author

@Fidget-Spinner Fidget-Spinner Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PyObject_SetAttr actually takes borrowed refs too, so this shouldn't be stolen. This was caught when the DECREF_INPUTS tried to close an already stolen stackref.

@Fidget-Spinner Fidget-Spinner merged commit e6543da into python:main Jun 28, 2024
59 checks passed
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Debian root 3.x has failed when building commit e6543da.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/345/builds/8384) and take a look at the build logs.
  4. Check if the failure is related to this commit (e6543da) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/345/builds/8384

Failed tests:

  • test_repl

Failed subtests:

  • test_asyncio_repl_is_ok - test.test_repl.TestInteractiveInterpreter.test_asyncio_repl_is_ok

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
xiting asyncio REPL...
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/asyncio/__main__.py", line 109, in run
    raise OSError(errno.ENOTTY, "tty required", "stdin")
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x000055da69db5ad0)


Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_repl.py", line 199, in test_asyncio_repl_is_ok
    assert_python_ok("-m", "asyncio")
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/script_helper.py", line 180, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/script_helper.py", line 165, in _assert_python
    res.fail(cmd_line)
    ~~~~~~~~^^^^^^^^^^
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/script_helper.py", line 75, in fail
    raise AssertionError("Process return code is %d\n"
    ...<13 lines>...
                            err))
AssertionError: Process return code is -6
command line: ['/root/buildarea/3.x.angelico-debian-amd64/build/python', '-X', 'faulthandler', '-I', '-m', 'asyncio']


Traceback (most recent call last):
xiting asyncio REPL...
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/asyncio/__main__.py", line 109, in run
    raise OSError(errno.ENOTTY, "tty required", "stdin")
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x000055bec2fccad0)

@Fidget-Spinner
Copy link
Member Author

It looks unrelated and more like a buildbot problem.

mrahtz pushed a commit to mrahtz/cpython that referenced this pull request Jun 30, 2024
noahbkim pushed a commit to hudson-trading/cpython that referenced this pull request Jul 11, 2024
estyxx pushed a commit to estyxx/cpython that referenced this pull request Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants