Bug report

Bug description:

The following code, invoked withpython3 ~/test.py foo:

importmultiprocessingimportsysprint("args in module",sys.argv[1:])deffun():print("args in fun",sys.argv[1:])if__name__=="__main__":multiprocessing.set_start_method("forkserver")fun()p=multiprocessing.Process(target=fun)p.start()p.join()

prints the following results on Python 3.12, 3.13.4, and 3.14.0b3:

args in module ['foo']args in fun ['foo']args in module ['foo']args in fun ['foo']

but on Python 3.13.11 and 3.14.2 prints the following results:

args in module ['foo']args in fun ['foo']args in module []args in fun ['foo']

For whatever reason, these latter versions changeforkserver to set upsys.argv after the main module is imported, instead of before. As far as I can tell, the former results are always printed usingspawn; that always sets upsys.argv before the main module is imported.

If the code depends onsys.argv in the main module, then the subprocess does not do the same thing as the main process and bad things can happen.

This change tripped me up when fixing a program for the newforkserver default. It's unclear if it's a bug, because I admit our program is naughty about running code in a module like this, but this may be something to fix and at least may serve as documentation of a pitfall for others even if there is nothing to change.

CPython versions tested on:

3.12, 3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

• gh-143706: Fix sys.argv not set during multiprocessing forkserver__main__ preload #143717
• [3.14] gh-143706: Fix sys.argv not set during multiprocessing forkserver__main__ preload (GH-143717) #143763
• [3.13] gh-143706: Fix sys.argv not set during multiprocessing forkserver__main__ preload (GH-143717) #143821