On 13Apr2020 1122, Steve Dower wrote:
On 11Apr2020 0111, Victor Stinner wrote:
Steve: the use case is to debug very rare Python crashes (ex: once every two months) of customers who fail to provide a reproducer. My *expectation* is that a debug build should help to reproduce the bug and/or provide more information when the bug happens. My motivation for this feature is also to show that the bug is not on Python but in third-party C extensions ;-)
I think your expectation is wrong. If a stack trace of the crash doesn't show that it belongs to the third party module (which most of the ones that are sent back on Windows indeed show), then you need more invasive tracing to show that the issue came from the module. Until we actually have opaque, non-static objects, that doesn't seem to be possible.
All you've done right now is enable new inconsistencies and potential issues when mixing debug and release builds. That just makes things harder to diagnose.
I think what you really wanted to do here was have a build option _other_ than the debug flag to turn on additional checks. Like you did with tracemalloc.
The debug flag turns on additional runtime checks in the underlying C compiler and runtime on Windows (and I presume elsewhere? Is this such a crazy idea?), such as buffer overrun detection and memory misuse. The only way to make a debug build properly compatible with a release build is to disable these checks, which leaves us completely unable to take advantage of them. It also significantly speeds up compile time, which is very useful as a developer.
But if your goal is to have a release build that includes additional ABI-transparent checks, then I don't see why you wouldn't just build with those options? It's not like CPython takes that long to build from a clean working directory.