Skip to content

As of 3.12 _lsprof no longer calls _PyEval_SetProfile making sys.getprofile() useless with cProfile #130377

Open

Description

@sivel

Bug report

Bug description:

Starting in 3.12 with the addition of sys.monitoring, _lsprof, specifically in profiler_enable, no longer calls _PyEval_SetProfile.

Very specifically, this impacts previous functionality where python -m cProfile -m whatever would result in sys.setprofile() being called, and subsequently the whatever module could access the profiler object via sys.getprofile()

To my knowledge this is now completely impossible as sys.monitoring provides no meaningful way to access the profiler object.

In my particular use case, profiling could be enabled within the application, or if python -m cProfile was used, the existing profiler could be used allowing profiling to happen earlier than the enablement point of cProfile within the application.

Something to the effect of:

p = sys.getprofile()
if p is None:
    p = cProfile.Profile()
    p.enable()

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Feb 20, 2025
  2. gaogaotiantian commented on Feb 20, 2025

    @gaogaotiantian
    Member

    This is not a bug. sys.getprofile gets the profile function from sys.setprofile, cProfile before 3.12 happened to use that specific utility for profiling. It switched to sys.monitoring mechanism after 3.12, so sys.getprofile won't get anything for cProfile. Yes they both have the word profile in it, but there's never a guarantee that they will always be related. cProfile documentation does not provide a way to get the profile object from CLI either. This is just something unsupported that happened to work before 3.12.

    If you just want something equivalent to your current method (which is not 100% accurate, it's only guarantees that if cProfile is running, sys.getprofile() will be not None), you can do sys.monitoring.get_tool(sys.monitoring.PROFILER_ID) - that will return a string if cProfile is running.

    Still, cProfile does not provide an official way to access it's profiler object in CLI mode, if you need that, that's a feature request.

  3. added
    3.12only security fixes
    3.13only security fixes
    3.14bugs and security fixes
    on Feb 21, 2025
  4. BHUVANSH855 commented on Oct 20, 2026

    @BHUVANSH855
    Contributor

    this came from PR #103534 which quietly removed the test assertions checking sys.getprofile() == prof with no changelog note.

    The real gap is that get_tool() gives you a string but no way to reach the object.

    Since PEP 799 is accepted and profiling.tracing lands in 3.15, a small addition makes sense:

    profiling.tracing.get_active() -> Profile | None

    use_tool_id already guarantees one owner, so the object is right there in _lsprof. Worth a feature request against profiling.tracing.
    @gaogaotiantian @pablogsal, happy to draft a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.12only security fixes3.13only security fixes3.14bugs and security fixesextension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions