STINNER Victor added the comment:
> I considered that, but then we'll be disabling the handler for calls into
> external modules (assuming whatever pyd layer exists is doing its job
> correctly), which is exactly where the error is most relevant.
Hum ok. So I try to rephrase the issue.
When Python is compiled in debug mode, the Windows C runtime (CRT) kills the
process when a fault is detected. A fault can be an invalid memory access, a C
assertion ("assert(...);") which failed, etc. The problem is that the Python
test suite explicitly call functions with invalid parameters to check that
Python "handles correctly" errors. The problem is that unit tests expect that
Python raises an exception, while the CRT kills the process by default.
You propose to modify the behaviour of the CRT of the current thread in the os
module to raise a regular exception, instead of killing the process.
I agree with your suggestion :-)
We already use _PyVerify_fd() to raises an OSError(EBADF) exception, instead of
killing the process when functions like os.close() are called with an invalid
file descriptor.
We cannot disable globally CRT checks because users want them (#3545 and #4804)
to validate their own C libraries. So CRT checks should only be disabled
temporary when a Python function of the stdlib is called. We expect that
calling a third party function kills the process if it is called with an
invalid parameter. It's the purpose of the debug build.
(I didn't review the patch yet.)
Note: "kill the process" probably means that Windows opens a popup to ask to
debug the application when a debugger is installed, instead of killing silently
the application.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
