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 — multiprocessing child segfault when passing lock as an argument · Issue #119413 · python/cpython

multiprocessing child segfault when passing lock as an argument #119413

New issue
Copy link
New issue
Copy link
Closed as not planned
Closed as not planned
multiprocessing child segfault when passing lock as an argument#119413
Copy link
Labels
pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is providedtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

Description

@DylanZA
DylanZA
opened on May 22, 2024
Issue body actions

Crash report

What happened?

It seems that the below code will serialize the pointer to the lock handle over to the child process, and then rebuild the raw pointer in https://github.com/python/cpython/blob/main/Modules/_multiprocessing/clinic/semaphore.c.h#L331

this then segfaults the child process - which seems to cause new children to spin up.

import multiprocessing
import os

def _init(l):
    print(os.getpid())
    print(l)

def main():
    ctx = multiprocessing.get_context(method="spawn")
    lock = multiprocessing.Lock()
    with ctx.Pool(1, initializer=_init, initargs=(lock,)) as pool:
        ret = pool.map(print, [1])

if __name__ == "__main__":
    main()

CPython versions tested on:

3.10, 3.11

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

No response

Activity

  1. DylanZA
    added
    type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
    on May 22, 2024
  2. DylanZA
    changed the title [-]multiprocessing segfault[/-] [+]multiprocessing child segfault when passing lock as an argument[/+] on May 22, 2024
  3. Eclips4 commented on May 22, 2024

    @Eclips4
    Eclips4
    on May 22, 2024
    Member
    More actions

    Hello! I guess this has been fixed in #107275. I cannot reproduce this in any of the 3.12, 3.13, or 3.14 branches. Versions lower than 3.12 do not accept bug fixes.

  4. Eclips4
    added
    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
    on May 22, 2024
  5. DylanZA commented on May 22, 2024

    @DylanZA
    DylanZA
    on May 22, 2024
    Author
    More actions

    right - that makes sense. sorry for the noise in that case

    Reacted by Kirill Podoprigora
  6. DylanZA
    closed this as completedon May 22, 2024
  7. Eclips4
    closed this as not plannedon May 22, 2024
  8. DylanZA commented on May 22, 2024

    @DylanZA
    DylanZA
    on May 22, 2024
    Author
    More actions

    fwiw for future people - the new error message makes it obvious that this change fixes the problem:

    - lock = multiprocessing.Lock()
    +lock = ctx.Lock()
    
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

    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is providedtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      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.