Opened 7 years ago

#4184 defect new

reactor.spawnProcess() handles file-not-found differently on different platforms

Reported by: TimAllen Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: Branch:


In #3292, I wrote some RPM-building tests, and added some code to skip them if the rpmbuild command was not found:

def checkForRpmbuild():
    def skipTestIfError(result):
	out, err, code = result
	if code != 0 or not out.startswith("RPM version"):
	    raise SkipTest("rpmbuild must be present to test tap2rpm")

    d = utils.getProcessOutputAndValue("rpmbuild", ("--version",))
    return d

On my Fedora workstation, this code worked fine - it found the installed rpmbuild binary, and the tests passed. On the various Ubuntu and Debian buildbots, this code worked fine - rpmbuild was not found, the process' return code was non-zero, and the tests were properly skipped. On the various Win32 buildbots, it broke horribly, with this traceback:

Traceback (most recent call last):
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\scripts\test\", line 94, in setUp
    return self._checkForRpmbuild()
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\scripts\test\", line 106, in _checkForRpmbuild
    d = utils.getProcessOutputAndValue("rpmbuild", ("--version",))
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\", line 169, in getProcessOutputAndValue
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\", line 25, in _callProtocolWithDeferred
    reactor.spawnProcess(p, executable, (executable,)+tuple(args), env, path)
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\", line 234, in spawnProcess
    return Process(self, processProtocol, executable, args, env, path)
  File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\", line 181, in __init__
    raise OSError(pwte)
exceptions.OSError: (2, 'CreateProcess', 'The system cannot find the file specified.')

It seems that on POSIX, calling spawnProcess() with a bogus command results in the callback being called; on Win32 it results in the errback being called, a behaviour likely to catch many people by surprise.

The spawnProcess() docs *do* say "OSError is raised errno EAGAIN or ENOMEM if there are insufficient system resources to create a new process." so anyone who calls spawnProcess() without handling OSError is technically in the wrong, but in that case the documentation still needs to be updated.

Exarkun has pointed out #3815 which doesn't mention a traceback, but does involve process-creation on Win32 being annoyingly non-POSIX. If someone with a Win32 machine determines this ticket is actually the same problem as that ticket, feel free to mark this as a duplicate.

Change History (1)

comment:1 Changed 6 years ago by <automation>

Owner: Glyph deleted
Note: See TracTickets for help on using tickets.