[issue24045] Behavior of large returncodes (sys.exit(nn))
New submission from Ethan Furman: Not sure if this is a bug, or just One of Those Things: sys.exit(large_value) can wrap around if the value is too large, but this is O/S dependent. linux (ubuntu 14.04) $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(256) $ echo $? 0 $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(257) $ echo $? 1 M$ (Windows 7)
python Python 2.7... --> import sys --> sys.exit(65535) echo %errorlevel% 65535
python Python 2.7... --> import sys --> sys.exit(100000) echo %errorlevel% 100000
Perhaps a minor doc update that talks about return codes and why they might not be exactly what was given to Python? ---------- assignee: docs@python messages: 241903 nosy: docs@python, ethan.furman priority: normal severity: normal status: open title: Behavior of large returncodes (sys.exit(nn)) versions: Python 2.7, Python 3.5 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue24045> _______________________________________
Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA@GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue24045> _______________________________________
Changes by Ethan Furman <ethan@stoneleaf.us>: ---------- nosy: -ethan.furman _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue24045> _______________________________________
Martin Panter added the comment: Is this a duplicate of Issue 24052? ---------- nosy: +martin.panter _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue24045> _______________________________________
Eryk Sun added the comment: Unix waitpid() packs the process exit status and terminating signal number into a single status value. As specified by POSIX [1], the WEXITSTATUS function returns only the lower 8 bits of the process exit status. In theory, waitid() and wait6() can return the full 32-bit status value in the siginfo_t si_status. Apparently NetBSD does this [2], but evidently Linux does not: >>> p = subprocess.Popen(['python3', '-c','import os; os._exit(257)']) >>> os.waitid(os.P_PID, p.pid, os.WEXITED).si_status 1 For Windows, programs sometimes return 16-bit WinAPI error codes or 32-bit HRESULT error codes. A critical error or unhandled exception may even result in returning a 32-bit NTSTATUS code (e.g. if you cancel the Windows error reporting dialog). Currently the Python 3 implementation of sys.exit and os._exit converts to a signed long, but the Windows exit code is an unsigned long. To use integer return codes in the range 0x80000000-0xFFFFFFFF requires manually converting to the corresponding negative signed value. Technically the two error types that require 32-bit values are signed (i.e. HRESULT and NTSTATUS), so this shouldn't be a problem. However, in practice sometimes a function -- and definitely subprocess.Popen -- returns an HRESULT error code as an unsigned value. It would be convenient, at least on Windows, if handle_system_exit in Python/pythonrun.c converted the value using PyLong_AsUnsignedLongMask instead of PyLong_AsLong. Similarly os._exit could use Argument Clinic's "unsigned int" format, which also calls PyLong_AsUnsignedLongMask. The problem with using PyLong_AsLong on Windows (32-bit or 64-bit) is that it overflows with an error value of -1 for values greater than 0x7FFFFFFF. In this case, os._exit raises OverflowError. handle_system_exit, on the other hand, ignores the exception. It just uses the -1 error value as the exit code, i.e. 0xFFFFFFFF. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html [2]: https://www.daemon-systems.org/man/wait.2.html ---------- nosy: +eryksun _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue24045> _______________________________________
Eryk Sun <eryksun@gmail.com> added the comment: It's still the case in 3.10 that unsigned status codes are limited to 0x7FFF_FFFF, and any larger value gets mapped to -1 (0xFFFF_FFFF). For example: >>> rc = subprocess.call([sys.executable, '-c', 'raise SystemExit(0x7FFF_FFFF)']) >>> hex(rc) '0x7fffffff' >>> rc = subprocess.call([sys.executable, '-c', 'raise SystemExit(0x8000_0000)']) >>> hex(rc) '0xffffffff' >>> rc = subprocess.call([sys.executable, '-c', 'raise SystemExit(0xC000_0005)']) >>> hex(rc) '0xffffffff' WinAPI ExitProcess() and GetExitCodeProcess() use unsigned values. The latter is called by subprocess.Popen.wait(). In practice, this return code, which may be larger than 0x7FFF_FFFF, might get passed to SystemExit() or os._exit(). ---------- type: -> behavior versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue24045> _______________________________________
participants (4)
-
Arfrever Frehtes Taifersar Arahesis -
Eryk Sun
-
Ethan Furman
-
Martin Panter