reactor.spawnProcess() handles file-not-found differently on different platforms
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 6k
- Forks
- 1.2k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 10
Description
| TimAllen reported | |
|---|---|
| Trac ID | trac#4184 |
| Type | defect |
| Created | 2009-12-22 02:52:23Z |
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",))
d.addCallback(skipTestIfError)
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\test_tap2rpm.py", line 94, in setUp
return self._checkForRpmbuild()
File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\scripts\test\test_tap2rpm.py", line 106, in _checkForRpmbuild
d = utils.getProcessOutputAndValue("rpmbuild", ("--version",))
File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\utils.py", line 169, in getProcessOutputAndValue
reactor)
File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\utils.py", line 25, in _callProtocolWithDeferred
reactor.spawnProcess(p, executable, (executable,)+tuple(args), env, path)
File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\posixbase.py", line 234, in spawnProcess
return Process(self, processProtocol, executable, args, env, path)
File "c:\twistedbot2\WXP32-full2.5-scmikes-select\Twisted\twisted\internet\_dumbwin32proc.py", 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.
Searchable metadata
trac-id__4184 4184
type__defect defect
reporter__TimAllen TimAllen
priority__normal normal
milestone__
branch__
branch_author__
status__new new
resolution__None None
component__core core
keywords__
time__1261450343000000 1261450343000000
changetime__1261450343000000 1261450343000000
version__None None
owner__
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with twisted/internet/posixbase.py and twisted/internet/_dumbwin32proc.py, then inspect twisted/scripts/test/test_tap2rpm.py and the spawnProcess documentation. Reproduce the missing-rpmbuild behavior on POSIX and Win32, and check issue #3815 for overlap. Done means the platform discrepancy is resolved or the documented behavior and affected test handling are made consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100