In Windows XP, using CPython 3.1.1:

python -c "import os; os.spawnl( os.P_WAIT, 'blah' )"

Crashes the interpreter and Windows pops up the "tell us about it" box.


Python 2.6 is however happy and just reports invalid arg.

Confirmed on trunk, release31-maint, and py3k on Windows. OS X returns 127 in that case.

In case it matters, 3.0.1 does NOT crash.

2.6 and 3.0.1 used to disable the Microsoft CRT argument error handler: they return EINVAL, but newer versions don't, and should check their arguments before calling _spawnv.

FWIW, the checks are::
    pathname != NULL
    *pathname != '\0'
    argv != NULL
    *argv != NULL
    **argv != '\0'
The first and third checks are guaranteed by the implementation, but the other three should be done in posix_spawnv().
And the other calls to the various nt.spawn* functions probably suffer the same problem.

Why is the Microsoft CRT argument error handler no longer disabled?

Because this is a global setting for the whole process. This was discussed with issue4804.

Should this just be resolved as a "won't fix"?

No, the issue can be fixed by better checking the arguments.

Attached first attempt to close this issue. Are there enough checks? It passes:
os.spawnl(os.P_WAIT, '')
os.spawnl(os.P_WAIT, 'path')
os.spawnl(os.P_WAIT, 'path', '')

This came up on python-list with
os.spawnl (os.P_NOWAIT, r"c:\windows\notepad.exe")
Tim Golden confirmed crash with Win7 on 2.7.?
I did same with 3.2.2 in both interpreter and from IDLE (IDLE hangs and then restarts after closing the 'pythonw has stopped' error message box).
Above apparently works in XP, at least with Py2.2.

@nvetoshkin: Can you please also write tests (in Lib/test/test_os.py) for your patch?

against py3k branch?

Now we are using Mercurial, and what was called 'py3k' on SVN is now 'default'.  Since we now commit on older branches first and then merge with the most recent ones, the patch should either be against 3.2 or 2.7.
You can check the devguide for more informations.

added some tests (not sure if in appropriate place).

All three test cases are raising a VallueError now:

C:\py\cpython3.8>python -c "import os; os.spawnl(os.P_WAIT, '')"
Running Debug|x64 interpreter...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\py\cpython3.8\\lib\os.py", line 931, in spawnl
    return spawnv(mode, file, args)
ValueError: spawnv() arg 2 cannot be empty

C:\py\cpython3.8>python -c "import os; os.spawnl(os.P_WAIT, '__not_existing_path__')"
Running Debug|x64 interpreter...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\py\cpython3.8\\lib\os.py", line 931, in spawnl
    return spawnv(mode, file, args)
ValueError: spawnv() arg 2 cannot be empty

C:\py\cpython3.8>python -c "import os; os.spawnl(os.P_WAIT, '__not_existing_path__', '')"
Running Debug|x64 interpreter...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\py\cpython3.8\\lib\os.py", line 931, in spawnl
    return spawnv(mode, file, args)
ValueError: spawnv() arg 2 first element cannot be empty


But the following one still causes a crash:

  python -c "import os; os.spawnl(os.P_WAIT, '', 'non-empty')"

Serhiy, an empty file path shouldn't crash the interpreter. The per-thread invalid parameter handler is suppressed before calling _wspawnv, so it should raise OSError (EINVAL) if the file path is empty. That's what I observe in 3.7. Are you suggesting to raise ValueError in this case instead of calling _wspawnv?

Crashing happens only with the debug build. With the release mode I got OSError(EINVAL). I think it is better to raise the same error in all builds. ValueError is not new, it is already raised for paths containing NUL and too long paths.

> Crashing happens only with the debug build.

I don't understand why Python behaves differently in debug mode. For me, if Python is able to trigger an exception on EINVAL, we should also get a regular Python exception in debug mode (and not a crash).

> I don't understand why Python behaves differently in debug mode.
> For me, if Python is able to trigger an exception on EINVAL, we 
> should also get a regular Python exception in debug mode (and not 
> a crash)

The debug build's behavior isn't related to the invalid parameter handler, and it's not necessarily a crash. The default report mode for CRT_ERROR and CRT_ASSERT is CRTDBG_MODE_WNDW. This pops up a dialog asking whether to abort the process, ignore the error (fail and set errno), or retry if a debugger is attached (i.e. break into the debugger with a first-chance exception).

The mode can be changed to CRTDBG_MODE_DEBUG, which writes a message to the debugger, if one is attached to the process:

    msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_DEBUG)

For example, in this case a message is written about the failed assertion in exec\spawv.cpp on line 276 (in this case the debugger is cdb, sharing the same console as Python, so the failed assertion message is inlined with Python's traceback):
    
    >>> os.spawnl(os.P_WAIT, '', 'non-empty')
    minkernel\crts\ucrt\src\desktopcrt\exec\spawnv.cpp(276) : Assertion failed: file_name[0] != '\0'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "C:\Program Files\Python37\lib\os.py", line 931, in spawnl
        return spawnv(mode, file, args)
    OSError: [Errno 22] Invalid argument

or set the report mode to CRTDBG_MODE_FILE with the file set to CRTDBG_FILE_STDERR:

    msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_FILE)
    msvcrt.CrtSetReportFile(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_FILE_STDERR)

The internal spawn function in ucrt, common_spawnv(), verifies its parameters as follows:

    _VALIDATE_RETURN(file_name       != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(file_name[0]    != '\0',    EINVAL, -1);
    _VALIDATE_RETURN(arguments       != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(arguments[0]    != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(arguments[0][0] != '\0',    EINVAL, -1);

Currently os.spawnv() and os.spawnve() check for and raise ValueError for all of these cases except the second one, in which file_name is an empty string. Microsoft doesn't document this case [1]:

    These functions validate their parameters. If either cmdname or argv 
    is a null pointer, or if argv points to null pointer, or argv[0] is 
    an empty string, the invalid parameter handler is invoked, as 
    described in Parameter Validation.

In a release build, this case fails with EINVAL. In a debug build, the default error-reporting settings display a pop message about the invalid argument. The message box is easy enough to suppress. But for the sake of consistency with the other cases, os_spawnv_impl in Modules/posixmodule.c should raise a ValueError if `path` is an empty string. For example:

    #ifdef HAVE_WSPAWNV
        if (!path->wide[0]) {
            PyErr_SetString(PyExc_ValueError,
                "spawnv() arg 1 cannot be an empty string");
            return NULL;
        }
    #endif

---
[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv