Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

NOTRACE_DISPATCH breaks tracing #96636

Closed
Closed
Labels
3.11only security fixes3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagerelease-blockertype-bugAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dump
@brandtbucher

Description

@brandtbucher

Most of our quickened instructions start by asserting that tracing isn't enabled, and end by callingNOTRACE_DISPATCH(), which skips tracing checks. This is safe for many of our specializations (like those forBINARY_OP andCOMPARE_OP, which operate on known safe types), but not all of them. The problem is that any time we decref an unknown object, arbitrary finalizers could run and enable tracing.

It seems that our current practice is predicated on the idea that it's okay for tracing to start "sometime in the future", since we make no guarantees about when finalizers run. There are two issues with this:

  • Trace functions may temporarily trace some frames, but not others.
  • As mentioned, the interpreter loop is littered with asserts that will fail if this happens.

Here's a sort-of-minimal reproducer of what this can look like on debug builds:

Python3.11.0rc1+ (heads/3.11:bb0dab5c48,Sep62022,22:29:10) [GCC9.3.0]onlinuxType"help","copyright","credits"or"license"formoreinformation.>>>classC:...def__init__(self,x):...self.x=x...def__del__(self):...ifself.x:...breakpoint()...>>>deff(x):...C(x).x,C...>>>for _inrange(8):...f(False)...>>>f(True)--Return--><stdin>(6)__del__()->None(Pdb)nextpython:Python/ceval.c:3076:_PyEval_EvalFrameDefault:Assertion `cframe.use_tracing==0'failed.Aborted

In this caseLOAD_ATTR_INSTANCE_VALUE'sNOTRACE_DISPATCH() invalidatesLOAD_GLOBAL_MODULE'sassert(cframe.use_tracing == 0).

One option is to just rip out the asserts, which solves the more serious issue of crashing debug builds. However, I think that the best solution may be to stop usingNOTRACE_DISPATCH() altogether. It's really hard to get right, and only saves us a single memory load and bitwise|. I benchmarked a branch that usesDISPATCH() for all instructions, and the result was "1.00x slower" thanmain.@markshannon tried the same thing, and got "1.01x slower". So going this route isn't free, but also not a huge penalty for correctness and peace-of-mind.

Flagging as a release blocker, since 3.11 is affected.

@markshannon@sweeneyde@pablogsal

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.11only security fixes3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagerelease-blockertype-bugAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp