Python turning off assertions (Windows)

[abe]

BPO	3545
Nosy	@loewis

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-08-14.13:38:12.165>
created_at = <Date 2008-08-12.10:05:30.955>
labels = ['type-bug', 'OS-windows']
title = 'Python turning off assertions (Windows)'
updated_at = <Date 2008-10-27.23:04:32.422>
user = 'https://bugs.python.org/abe'

bugs.python.org fields:

activity = <Date 2008-10-27.23:04:32.422>
actor = 'kevinwatters'
assignee = 'none'
closed = True
closed_date = <Date 2008-08-14.13:38:12.165>
closer = 'loewis'
components = ['Windows']
creation = <Date 2008-08-12.10:05:30.955>
creator = 'abe'
dependencies = []
files = []
hgrepos = []
issue_num = 3545
keywords = []
message_count = 6.0
messages = ['71049', '71066', '71077', '71097', '71117', '71127']
nosy_count = 3.0
nosy_names = ['loewis', 'kevinwatters', 'abe']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3545'
versions = ['Python 2.5']

[abe]

We are using Windows XP SP2, Visual Studio 2005 & Python 2.5.2.
In Objects/exceptions.c the following code turns off all assertions.

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
    /* Set CRT argument error handler */
    prevCrtHandler = _set_invalid_parameter_handler
(InvalidParameterHandler);
    /* turn off assertions in debug mode */
    prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

As far as I understand, this is to make sure that no assertion dialogs
pop up during the internal Python tests. For ordinary users, this is
not an issue.

However, we are using the Python DLL in our product and when developing
we always use the debug version of the Python DLL (as recommended).
When we do Py_Initialize() all assertions are turned off, even our
assertions, and this is not what we want. The current workaround is as
follows (this is in our code):

   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_REPORT_MODE);
   Py_Initialize();
   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,prevCrtReportMode);

I am not certain if this is a bug or a feature and I really do not have
a suggested solution since I do not know the real reasons for turning
off assertions. Perhaps there already is a way to avoid this problem
that I have not found?

All comments are appreciated.

[loewis]

As you must be building your own Python DLL, anyway, can't you just
simply remove that code if you don't want it?

[abe]

Yes, we could do that. However, my concerns are:

1. We cannot be the only Python user that experience this issue? I
   would prefer one of these solutions (in this order):
   a) A parameter to Py_Initialize (structure) that controls its
   behaviour.
   b) A #define in pyconfig.h controls whether this should be done or not.
   However, since I am not a Python developer myself, I cannot judge how
   much this would affect other things. I also realize that this involves
   some work and that it has very low priority.
2. We have to remember to do this change every time we upgrade to a
   newer version of Python. In earlier releases of Python where
   PyImport_AppendInittab did not exist, we had to do changes to the
   Python code every time we upgraded which was a hazzle. This is why I
   prefer the current workaround we are using where we reset the CRT
   report mode after Py_Initialize().
   Your efforts are much appreciated and I realize that the current
   workaround we are using will probably be the final solution.

[loewis]

2. We have to remember to do this change every time we upgrade to a
   newer version of Python.

Every new MSVC release brings new problems, as far back as I remember.
Did you actually try to turn it off? Did it work? What if you do
'open("foo","bar")'? IIRC, turning this CRT checking code back on,
regular Python code can now crash Python, by triggering a CRT
assertion (these assertions are stupid, in the sense that they ban
behavior that is completely conforming to the ISO C standard, and
consider it incorrect). Turning off the assertions is the only
supported way to override the CRT behavior to crash the application.

I don't quite understand why this all affects your code. Are you
using ASSERT() by any chance? If so, why are you not using assert()
instead? That doesn't go through CrtDebugReport, AFAICT.

[abe]

We started using Python 2.5.2 recently and a few developers have
complained that they do not get any assertions anymore so yes, we do
use _ASSERT() and _ASSERTE(), but after a brief look it seems as if we
mainly use assert(). The developer using _ASSERT() cannot remember why
this was necessary and the tests I have made today shows that we could
probably move to assert() everywhere.

A more interesting aspect is that we have recently moved the the more
secure CRT routines (strcpy_s etc) and tests have shown issues with
these if we turn off assertions:

 int prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,0);
 char str[8];
 strcpy_s(str,"123456789");

With assertions turned on, I get an assertion dialog saying "Buffer is
too small" which is what I expect and want. With assertions turned off
(as in the example above), I get a dialog saying "Microsoft Visual
Studio C Runtime Library has detected a fatal error in crt.exe.".

The stack is still useful and we can find the cause of the error so it
is not a serious problem for us since we will continue to turn on
assertions after Py_Initialize().

I have not yet seen any examples where the are erroneous assertions.

Anyway, you have made your point and I really do not want to take up
anymore of your time. I respect your opinion and at least I have forced
you to think about this. We have a workaround that works for us so I am
OK with closing this issue.

Many thanks!

[loewis]

I have not yet seen any examples where the are erroneous assertions.

Please take a look at the code in signalmodule.c. The MS CRT asserts
that the signal number is supported (i.e. among a fixed list of signal
numbers), even though C 99, 7.14.1.1p8 says that the library shall
return SIG_ERR, and set errno to a positive value, if the request cannot
be honored.