Skip to content

#138473 backports to 3.13 & 3.14 break running programs on Python version upgrade (multiprocessing) #142206

Closed

Description

@mgorny

Bug report

Bug description:

#138473 changed the format used to pass data between the parent process and subprocesses in multiprocessing. This change has been backported as-is to Python 3.14.1 and FWICS 3.13.10. Unfortunately, this means that if Python is upgraded to a newer patch version while applications are running using this Python version, newly started subprocesses suddenly start using the new data format that is incompatible with the parent process. I think such a change is acceptable for 3.15 now, but this is a major issue with 3.13 & 3.14, because it literally means we would have to tell our users "please restart all programs after upgrading Python, or things may silently break".

I'm sorry but I don't have a traceback handy, but it broke Gentoo's package manager for me mid-upgrade, with the parent process starting to throw JSONDecodeErrors at the non-JSON data provided by children.

Kudos to @thesamesam for finding the offending change.

CPython versions tested on:

3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Dec 3, 2025
  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    3.13only security fixes
    3.14bugs and security fixes
    on Dec 3, 2025
  3. gpshead commented on Dec 3, 2025

    @gpshead
    Member

    FWIW there are a lot of problems with upgrading a Python installation across patch releases in-place that have happened over the years. I don't think this is nearly as common of a thing to do as it was 10-20y ago given the worlds use of containers.

    We don't have regression tests for this concept (and the test matrix would be quite huge as it'd need to test .N to any .N+M patch upgrade).

    Gentoo with I presume emerge still being a Python application (sorry it's been too long since i've run gentoo) got bitten hard I guess?

  4. mgorny commented on Dec 3, 2025

    @mgorny
    ContributorAuthor

    Gentoo with I presume emerge still being a Python application (sorry it's been too long since i've run gentoo) got bitten hard I guess?

    Yep. The package manager uses multiprocessing to install packages, so the top process couldn't communicate with running installs anymore.

  5. gpshead commented on Dec 3, 2025

    @gpshead
    Member

    the old IPC message format prior to the PR that got backported was msg = f"{cmd}:{name}:{rtype}\n".encode("ascii") - we could still use that format and parse names that have ':' in them by splitting/partitioning only on the first and last colon without reinventing the format. just brainstorming; that'd probably work as a fix for 3.13 and 3.14 (no need to change main/3.15)

  6. eli-schwartz commented on Dec 3, 2025

    @eli-schwartz
    Contributor

    Yes, the issue as I understand it was that the communication format was changed in a point release, and the new subprocesses didn't have code to understand the old parent process.

    It's a standard mechanism for compatible updates, to simply support reading both formats but only emit one of them. So that should work fine. (And something like this is useful to keep in mind for consideration whenever backporting changes into a previously released version as a bugfix.)

  7. added a commit that references this issue on Dec 3, 2025
  8. encukou commented on Dec 3, 2025

    @encukou
    Member

    Sorry for the issue. I've sent a PR to make this more robust.

  9. changed the title [-]#138473 backports to 3.13 & 3.14 break running programs on Python version upgrade[/-] [+]#138473 backports to 3.13 & 3.14 break running programs on Python version upgrade (multiprocessing)[/+] on Dec 3, 2025
  10. added a commit that references this issue on Dec 3, 2025
  11. added a commit that references this issue on Dec 3, 2025
  12. radi2015 commented on Dec 4, 2025

    @radi2015

    /usr/local/lib/python3.14/multiprocessing/resource_tracker.py:369: UserWarning: resource_tracker: There appear to be 8 leaked semaphore objects to clean up at shutdown: {'/mp-p5mvdjr_', '/mp-eod2j56x', '/mp-259nug50', '/mp-kao00ric', '/mp-ajx2y7ng', '/mp-kmq460kb', '/mp-7__h1ds3', '/mp-ld509vj2'}
    warnings.warn(

  13. added 2 commits that reference this issue on Dec 5, 2025
  14. added a commit that references this issue on Dec 5, 2025
  15. added a commit that references this issue on Dec 5, 2025
  16. mgorny commented on Dec 5, 2025

    @mgorny
    ContributorAuthor

    Thanks a lot!

  17. added a commit that references this issue on Dec 6, 2025
  18. therealsickonechase-bit commented on Dec 12, 2025

    @therealsickonechase-bit
  19. Simonkx36 commented on Jan 2, 2026

    @Simonkx36
  20. dragon081 commented on Jan 6, 2026

    @dragon081
  21. hugovk commented on Jan 6, 2026

    @hugovk
    Member

    @dragon081 reported to GH.

  22. locked as resolved and limited conversation to collaborators on Jan 6, 2026
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.13only security fixes3.14bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytopic-multiprocessingtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions