Thanks to visit codestin.com
Credit goes to github.com

Skip to content

multiprocessing child segfault when passing lock as an argument #119413

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DylanZA opened this issue May 22, 2024 · 3 comments
Closed

multiprocessing child segfault when passing lock as an argument #119413

DylanZA opened this issue May 22, 2024 · 3 comments
Labels
pending The issue will be closed if no feedback is provided type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@DylanZA
Copy link

DylanZA commented May 22, 2024

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

@DylanZA DylanZA added the type-crash A hard crash of the interpreter, possibly with a core dump label May 22, 2024
@DylanZA DylanZA changed the title multiprocessing segfault multiprocessing child segfault when passing lock as an argument May 22, 2024
@Eclips4
Copy link
Member

Eclips4 commented May 22, 2024

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.

@Eclips4 Eclips4 added the pending The issue will be closed if no feedback is provided label May 22, 2024
@DylanZA
Copy link
Author

DylanZA commented May 22, 2024

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

@DylanZA DylanZA closed this as completed May 22, 2024
@Eclips4 Eclips4 closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2024
@DylanZA
Copy link
Author

DylanZA commented May 22, 2024

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
Labels
pending The issue will be closed if no feedback is provided type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

2 participants