segmentation-fault/core dump when try to run non-existing file specified on commandline (pymain_run_filename)

docker-library/python#320

bug was probably introduced here: 1976086#diff-75445bdc3b6b3dd20b005698fa165444R2443 (but I did not test the version from before that commit)

Did a quick cross-check with other Distro.
With a debian stretch for example there is no SEGV and core-dump but a "(null)" output for program name instead.

eohm: thank you for your bug report and great job of your analysis of the root cause! Your PR works as expected, but I prefer to get the current core configuration rather than keeping our old copy longer than previously in main.c. I wrote a PR 9526 to reorganize the code to make it closer to the master branch: clarify the lifetime of the "local config" in main.c, and as soon as possible, switch to the core configuration attached to the interpreter state.

Note: the master branch is not affected, I already fixed the bug in master. My PR backports the fix.

New changeset ddc163d by Victor Stinner in branch '3.7':
bpo-34783: Fix Py_Main() (GH-9526)
ddc163d

I wrote a non regression test: PR 9535.

New changeset a46467f by Victor Stinner in branch 'master':
bpo-34783: Add test_cmd_line_script.test_nonexisting_script() (GH-9535)
a46467f

New changeset 7a26222 by Miss Islington (bot) in branch '3.7':
bpo-34783: Add test_cmd_line_script.test_nonexisting_script() (GH-9535)
7a26222

Thank you again eohm for your bug report and your analysis. Sadly, I chose to fix the issue differently, to reduce the maintenance burden on main.c: make the code closer to the master branch. My change is part of a long serie of changes to rework the Python initialization.

I added non regression test to 3.7 and master as well.

Re-opening. The new test_cmd_line_script fails on macOS framework builds because the test case assumes that the file name in sys.executable will appear in the error message. For macOS framework builds, sys.executable is the file name of the stub launcher and its file name bears no relationship to the file name of the actual python executable:

$ python3.7 -c 'import sys;print(sys.executable)'
/usr/local/bin/python3.7
$ python3.7 -m test test_cmd_line_script
Run tests sequentially
0:00:00 load avg: 1.12 [1/1] test_cmd_line_script
test test_cmd_line_script failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/test_cmd_line_script.py", line 648, in test_nonexisting_script
    self.assertIn(program, err)
AssertionError: 'python3.7' not found in "/Library/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'nonexistingscript.py': [Errno 2] No such file or directory\n"

test_cmd_line_script failed

For now, I'm going to disable the test for macOS frameworks but the test should get fixed.

New changeset f6c29a6 by Ned Deily in branch 'master':
bpo-34783: Disable test_nonexisting_script for macOS framework builds (GH-9831)
f6c29a6

New changeset 5d8ef8b by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-34783: Disable test_nonexisting_script for macOS framework builds (GH-9831) (GH-9832)
5d8ef8b

New changeset ea75187 by Victor Stinner in branch 'master':
bpo-34783: Fix test_nonexisting_script() (GH-9896)
ea75187

New changeset 350aeab by Miss Islington (bot) in branch '3.7':
bpo-34783: Fix test_nonexisting_script() (GH-9896)
350aeab

The issue should be fixed now, I close it again.