GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — bpo-29548: Recommend PyObject_Call APIs over PyEval_Call APIs. by methane · Pull Request #75 · python/cpython

Conversation

@methane

@methane methane commented Feb 13, 2017 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

PyEval_Call* APIs are not documented and they doesn't respect PY_SSIZE_T_CLEAN.
So add comment block to recommend them where PyEval_Call APIs are declared.

This commit also changes PyEval_CallMethod and PyEval_CallFunction implementation
same to PyObject_CallMethod and PyObject_CallFunction.

PyEval_CallFunction(callable, "i", (int)i) now calls callable(i) instead of raising TypeError.

I expect this allows compiler to share some code between PyEval_CallFunction and PyObject_CallFunction. But I'm not sure.


[bpo-29548]

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@methane
methane requested a review from vstinner February 13, 2017 17:38
@the-knights-who-say-ni the-knights-who-say-ni added the CLA signed label Feb 13, 2017
Carreau
Carreau reviewed Feb 14, 2017
View reviewed changes
Comment thread Include/ceval.h Outdated

@Carreau Carreau Feb 14, 2017

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

did you ment Use PyObject_Call() it seem like this patch remove PyObject_CallObject ... Autocompleter got a bit overzealous ?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Feb 14, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

This patch deprecates PyEval_CallObject, not PyObject_CallObject.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@Carreau Carreau Feb 14, 2017

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

Oh, sorry, I got confused with the unified diff and above comment, the proximity of PyObject_Call() and PyObject_CallObject() made me think you had an Object too much in the comment.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Feb 14, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

There are so many similar call APIs.
That's why I think we should deprecate undocumented and less used APIs.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@methane
methane force-pushed the deprecate-evalcall branch from df67bdc to 89c7440 Compare February 14, 2017 14:32
@methane methane changed the title bpo-29548: deprecate PyEval_Call APIs. bpo-29548: Stop using PyEval_Call* APIs. Feb 14, 2017
@methane
methane force-pushed the deprecate-evalcall branch from 89c7440 to 76737a6 Compare February 14, 2017 14:41
@codecov

codecov Bot commented Feb 14, 2017

Copy link
Copy Markdown

Codecov Report

❗ No coverage uploaded for pull request base (master@c33ee85). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #75   +/-   ##
=========================================
  Coverage          ?   82.38%           
=========================================
  Files             ?     1428           
  Lines             ?   351138           
  Branches          ?        0           
=========================================
  Hits              ?   289281           
  Misses            ?    61857           
  Partials          ?        0

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c33ee85...76737a6. Read the comment docs.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@methane
methane force-pushed the deprecate-evalcall branch 2 times, most recently from 04111c1 to 7b1dd6e Compare February 14, 2017 15:13
@vstinner

vstinner commented Feb 15, 2017

Copy link
Copy Markdown
Member

Sorry but I'm confused by the PR title and the commit messages. They don't describe exactly what I see in the code. Can you please update them?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@methane methane changed the title bpo-29548: Stop using PyEval_Call* APIs. bpo-29548: Recomend PyObject_Call APIs over PyEval_Call* APIs. Feb 16, 2017
@methane

methane commented Feb 16, 2017

Copy link
Copy Markdown
Member Author

I updated pull request title and body.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ncoghlan ncoghlan changed the title bpo-29548: Recomend PyObject_Call APIs over PyEval_Call* APIs. bpo-29548: Recommend PyObject_Call APIs over PyEval_Call* APIs. Feb 19, 2017
ncoghlan
ncoghlan previously requested changes Feb 19, 2017
View reviewed changes

@ncoghlan ncoghlan left a comment •
edited by methane
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

For the PyEval_*/PyObject_* functions that are now duplicates, it would be useful to have block comments explaining the equivalence, and the fact the redundant definitions are being kept around for backwards compatibility reasons.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@methane
methane dismissed ncoghlan’s stale review February 20, 2017 01:18

fixed

@methane methane mentioned this pull request Feb 20, 2017
Review dismissal python/core-workflow#36
Closed
@methane

methane commented Feb 28, 2017

Copy link
Copy Markdown
Member Author

@Haypo Would you review this again?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

vstinner
vstinner requested changes Feb 28, 2017
View reviewed changes
Comment thread Objects/call.c Outdated

@vstinner vstinner Feb 28, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

I don't understand why you change the code in this commit, and 2 commits later reverts this change. You should practice git rebase -i HEAD~4 to merge the two commits maybe?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Objects/call.c Outdated

@vstinner vstinner Feb 28, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

Please update the commit message which doesn't make sense compared to the modified code.

This commit fixes a bug, no? It makes sure that a TypeError is raised if kwargs is not a dictionary, right? Please explain it in the commit message.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Mar 1, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

I remove this bugfix for now and update #87 instead.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Mar 1, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

done. I created split issue for #87.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Objects/call.c Outdated

@vstinner vstinner Feb 28, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

maybe use an else here?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Objects/call.c Outdated

@vstinner vstinner Feb 28, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

commit message: this change also optimizes PyEval_CallFunction() and PyEval_CallMethod() to avoid temporary tuple when possible.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Mar 1, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

Main purpose is reducing maintenance cost rather than optimization.
There are very few callers in the world.

I hope compiler can remove duplicated code too, but I'm not sure.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Include/ceval.h Outdated

@vstinner vstinner Feb 28, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

I don't understand the "are documented" part, maybe remove it?

I suggest to be more explicit:

" PyEval_CallObjectWithKeywords() is kept for backward compatibility: PyObject_Call(), PyObject_CallFunction() and PyObject_CallMethod() are recommended to call a callable object."

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@methane methane Mar 1, 2017

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

done

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@vstinner

vstinner commented Feb 28, 2017

Copy link
Copy Markdown
Member

I'm not confortable yet with GitHub to review commit messages :-/ It's not easy to comment the commit message: I also suggest to add "bpo-29548" to commit messages (at least to one commit message).

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@methane methane changed the title bpo-29548: Recommend PyObject_Call APIs over PyEval_Call* APIs. bpo-29548: Recommend PyObject_Call APIs over PyEval_Call APIs. Mar 1, 2017
@methane

methane commented Mar 1, 2017

Copy link
Copy Markdown
Member Author

I'm not confortable yet with GitHub to review commit messages :-/ It's not easy to comment the commit message:

I agree. I like Gerrit for this.

I also suggest to add "bpo-29548" to commit messages (at least to one commit message).

Final commit message is written when pushing "Squash and merge" button.
So I updated pull request title and body. The title will be first line of commit message, and the body follows.

I hope it works as poor man's Gerrit for a while, until we have new tool to build Misc/NEWS.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@methane
methane force-pushed the deprecate-evalcall branch 2 times, most recently from 3272dba to e17b495 Compare March 1, 2017 09:26
@methane
bpo-29548: Recommend PyObject_Call APIs over PyEval_Call APIs.
4a3c0d5
PyEval_Call* APIs are not documented and they doesn't respect PY_SSIZE_T_CLEAN.
So add comment block to recommend PyObject_Call* APIs where they are declared.

This commit also changes PyEval_CallMethod and PyEval_CallFunction
implementation same to PyObject_CallMethod and PyObject_CallFunction
to reduce future maintenance cost.  Optimization to avoid temporary
tuple are copied too.

PyEval_CallFunction(callable, "i", (int)i) now calls callable(i) instead of
raising TypeError.  But accepting this edge case is backward compatible.
@methane
methane force-pushed the deprecate-evalcall branch from e17b495 to 4a3c0d5 Compare March 1, 2017 09:32
@methane

methane commented Mar 1, 2017

Copy link
Copy Markdown
Member Author

I squashed all commit and modified commit message.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@methane
methane merged commit aa289a5 into python:master Mar 14, 2017
@methane
methane deleted the deprecate-evalcall branch March 14, 2017 09:01
@methane methane mentioned this pull request Aug 30, 2022
Recommend PyObject_Call* APIs over PyEval_Call*() APIs #73734
Closed
jaraco pushed a commit that referenced this pull request Dec 2, 2022
@pyup-bot @asvetlov
Update aiohttp from 3.0.8 to 3.0.9 (#75)
81eb6cf
oraluben pushed a commit to oraluben/cpython that referenced this pull request Jul 15, 2023
@Fidget-Spinner @JuliaPoo
docs: update readme with JIT (python#75)
5a26cb9
Co-authored-by: Jules <[email protected]>
@gvanrossum gvanrossum mentioned this pull request Aug 22, 2023
heap-use-after-free in _PyFunction_LookupByVersion #108253
Closed
lysnikolaou referenced this pull request in lysnikolaou/cpython May 1, 2024
@pablogsal
Merge pull request #75 from lysnikolaou/pyrepl-eol-move-up-down
390d778
Stay at eol when moving up/down
@ngoldbaum ngoldbaum mentioned this pull request Sep 23, 2024
Crash running PyO3 tests with --test-threads=1000 #124375
Closed
This was referenced Feb 11, 2025
segmentfault when pip installing setuptools #129992
Closed
segmentfault when pip installing setuptools #129993
Closed
@sergey-miryanov sergey-miryanov mentioned this pull request Dec 18, 2025
Observed memory leak in ssl library: Python 3.14 GC issue #142516
Closed
@ngoldbaum ngoldbaum mentioned this pull request Mar 6, 2026
Remove deprecated and undocumented function ctypes.SetPointerType #133866
Closed
SonicField added a commit to SonicField/cpython that referenced this pull request Apr 4, 2026
@SonicField
B5 hardening: delete OperandBase copy assignment operator
2337e9e
Prevents accidental shallow copy of raw MemoryIndirect* in value_.indirect,
which would create double-free risk. The copy constructor deliberately skips
value_ (safe); this ensures assignment doesn't silently shallow-copy it.

Per gatekeeper recommendation (20:34) and Pythia assessment python#75.
SonicField added a commit to SonicField/cpython that referenced this pull request Apr 16, 2026
@SonicField
Fix latent use-after-free: swap env/cfg declaration order in Function
9c8074b
C++ destroys members in reverse declaration order. With cfg before env,
env destructs first — freeing Registers while cfg still holds
Instructions with FrameState Register* pointers into env memory.

Swap: env now declared before cfg, so env outlives cfg during
destruction. FrameState's borrowed Register* pointers remain valid
throughout cfg teardown.

Found by Pythia assessment python#75. Currently safe by coincidence
(~FrameState only frees the buffer, never dereferences), but any
future dereference during destruction would be use-after-free.
SonicField added a commit to SonicField/cpython that referenced this pull request Apr 22, 2026
@SonicField
fix(global_cache): Py_IsFinalizing guards on dict-watcher + clear()
bf8982b
ARM64 pydebug shutdown SEGV root-cause: GlobalCacheKey holds raw
PyDictObject* pointers to globals/builtins. When globals is freed
during Py_FinalizeEx (interpreter_clear → PyDict_Clear), the cache
entry remains in map_ + watch_map_[builtins]. Subsequent
PyDict_EVENT_CLEARED on builtins triggers updateCache, which derefs
cache.key().globals → use-after-free. Pydebug poison fill (0xdd...)
makes the UAF a hard SEGV; x86_64 release reads stale-but-readable
type pointer and silently passes the JIT_CHECK.

Two surgical guards address the FINALIZE-SPECIFIC manifestation:

  Part A — Python/jit_support/phoenix_init.cpp
    phoenix_dict_watcher early-returns when Py_IsFinalizing(). Cache
    state is about to be destroyed in phoenix_free; processing events
    on tearing-down dicts is moot. Pattern matches pyjit.cpp:1642
    funcDestroyed precedent.

  Part B — Python/jit/global_cache.cpp
    GlobalCacheManager::clear() short-circuits when Py_IsFinalizing().
    Avoids two failure modes:
      1. Ci_Watchers_UnwatchDict (PyDict_Unwatch) reads dict internals
         on freed memory → UAF under pydebug
      2. ci_watcher_state_fini ran first in phoenix_free → watcher_id
         is -1 → JIT_CHECK 'Invalid dict watcher ID -1' abort
         (observed in earlier gate logs, regression historically)

SCOPE HONESTY: this is FINALIZE-SPECIFIC protection, NOT full
root-cause for the raw-pointer-aliasing class. Mid-execution module
unload (refcount→0 on globals while cache holds raw pointer) remains
unaddressed. Filed as W27 GlobalCacheKey raw-pointer lifecycle
re-architecture (docs/w27-globalcachekey-lifecycle.md, Tier 6+ scope).
The 314d0f2 'weak reference semantics' comment was FALSIFIED — no
mechanism actually provided weak-reference semantics; comments updated
to name the actual mechanisms (Py_IsFinalizing guard, finalize-only
protection).

Diagnostic evidence (per Debug-First protocol):
  lldb backtrace on ARM64 pydebug push 59 falsifier:
    PyType_HasFeature(type=0xdddddddddddddddd) object.h:966  <-- SEGV
    hasOnlyUnicodeKeys()                       dict.h:52
    GlobalCacheManager::updateCache()          global_cache.cpp:325
    GlobalCacheManager::notifyDictClear()      global_cache.cpp:144
    phoenix_dict_watcher()                     phoenix_init.cpp:58
    PyDict_Clear → interpreter_clear → Py_FinalizeEx

Test plan post-commit:
  testkeeper ARM64 pydebug --clean rebuild + falsifier rerun
  (test_phoenix_jit_inline_except_closure under timeout+redirect)
  + push 58 baseline regression check (8b7b935 still passes).

testkeeper x86_64 compile-only PASS verified pre-commit at
binary timestamp 1776874355 (chat L1872 build verification).

Authorization chain: supervisor option (i) at chat L1862, theologian
LEVEL-1 ratification at chat L1861. Pythia python#75 python#1 (trigger isolation)
gates downstream emitCallExceptionHandler queue, NOT this fix.
SonicField added a commit to SonicField/cpython that referenced this pull request Apr 22, 2026
@SonicField
docs: W27 ownership + falsification test + entry-trigger schedule
68b9b86
Per pythia python#76 [chat 16:45Z] + supervisor revision [chat 16:45Z python#3]:
filed-not-owned workstreams accrue weed-debt ('a field marked for
fallow grows weeds named next year'). W27 was filed at bf8982b
without ownership, falsification test, or revisit-trigger.

Added §1 frontmatter:
  - Owner: theologian (design), generalist (implementation)
  - Schedule: entry-trigger = Tier 5 ZERO C++ complete + no active
    push-class blocker; exit by start of cinderx Tier 6 cleanup
  - Falsification test reference: §8

Added §8 falsification test sketch:
  Lib/test/test_phoenix_w27_module_unload_uaf.py
  - SKIPPED until W27 work begins
  - Reproducer: register cache entry → del sys.modules → gc.collect →
    fire builtins event → expect SEGV pre-W27 / clean post-W27
  - Acceptance: reproduces SEGV pre-W27 + passes post-W27, OR W27
    scope re-opens if reproducer is harder to trigger than predicted
  - Discipline: 'falsification-first' — test lands before fix code

Added §7 cross-references:
  - Push 58 ARM64-pydebug coredump finding from testkeeper [chat
    16:45Z]: 8b7b935 baseline ALSO produces shutdown coredump
    on the same falsifier workload (just non-deterministic vs push
    59's deterministic SEGV) — independent confirmation that this
    is pre-existing latent (pythia python#75 b1 outcome) not push-59-port-
    shape-specific
  - W27 ownership update authority chain

This commit IS supervisor's pythia python#76 python#3 corrective action — turning
'filed' into 'owned, scheduled, testable'. Pattern reusable: same
audit will be applied to W23 (verifier hardening), W25 (typed bridges),
W26 (build-state hardening) per supervisor [chat 16:45Z python#3] deferral.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vstinner vstinner vstinner requested changes
@ncoghlan ncoghlan ncoghlan left review comments
+1 more reviewer
@Carreau Carreau Carreau left review comments
Reviewers whose approvals may not affect merge requirements

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

5 participants

@methane @vstinner @Carreau @ncoghlan @the-knights-who-say-ni
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.