You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2008/01/28 21:26:21 UTC
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
faridz@apache.org wrote:
> Author: faridz
> Date: Mon Jan 28 11:05:36 2008
> New Revision: 616003
>
> URL: http://svn.apache.org/viewvc?rev=616003&view=rev
> Log:
> 2008-01-28 Farid Zaripov <fa...@epam.com>
>
> STDCXX-712
> * tests/utilities/20.temp.buffer.cpp [_MSC_VER]: Disabled
> "Invalid allocation size: 4294967292 bytes" message box from malloc().
>
> Modified:
> stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>
> Modified: stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp?rev=616003&r1=616002&r2=616003&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp (original)
> +++ stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp Mon Jan 28 11:05:36 2008
> @@ -35,6 +35,7 @@
>
> #ifdef _MSC_VER
> # include <climits> // for INT_MAX
> +# include <crtdbg.h> // for _CrtSetReportMode()
> #endif
>
> #include <rw_new.h>
Should we do this in <rw_new.h> (or new.cpp, on the first call
to operator new or operator delete) instead?
Martin
> @@ -475,6 +476,12 @@
>
> int main (int argc, char *argv[])
> {
> +#ifdef _MSC_VER
> + // disable "Invalid allocation size: 4294967292 bytes"
> + // message box from malloc()
> + _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> +#endif
> +
> return rw_test (argc, argv, __FILE__,
> "lib.temporary.buffer",
> 0 /* no comment */,
>
>
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Martin Sebor wrote:
>> faridz@apache.org wrote:
>>> @@ -35,6 +35,7 @@
>>>
>>> #ifdef _MSC_VER
>>> # include <climits> // for INT_MAX
>>> +# include <crtdbg.h> // for _CrtSetReportMode()
>>> #endif
>>>
>>> #include <rw_new.h>
>> Should we do this in <rw_new.h> (or new.cpp, on the first call
>> to operator new or operator delete) instead?
>>
>> Martin
>>
>
> Seems that we would want to do something like this in the test driver...
>
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_FILE);
> _CrtSetReportFile (_CRT_WARN, _CRTDBG_FILE_STDERR);
>
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_FILE);
> _CrtSetReportFile (_CRT_ERROR, _CRTDBG_FILE_STDERR);
>
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_FILE);
> _CrtSetReportFile (_CRT_ASSERT, _CRTDBG_FILE_STDERR);
>
> That way all tests using the driver would dump failures to the console, much
> like they would on a *nix system. Is there any reason to _not_ do this?
We're already doing exactly this in the Rogue Wave test driver
(which the stdcxx test driver links with in our nightly builds)
but not in our own. I agree we should.
Martin
>
> Travis
Re: svn commit: r616003 -
/stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> faridz@apache.org wrote:
>> @@ -35,6 +35,7 @@
>>
>> #ifdef _MSC_VER
>> # include <climits> // for INT_MAX
>> +# include <crtdbg.h> // for _CrtSetReportMode()
>> #endif
>>
>> #include <rw_new.h>
>
> Should we do this in <rw_new.h> (or new.cpp, on the first call
> to operator new or operator delete) instead?
>
> Martin
>
Seems that we would want to do something like this in the test driver...
_CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_FILE);
_CrtSetReportFile (_CRT_WARN, _CRTDBG_FILE_STDERR);
_CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_FILE);
_CrtSetReportFile (_CRT_ERROR, _CRTDBG_FILE_STDERR);
_CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_FILE);
_CrtSetReportFile (_CRT_ASSERT, _CRTDBG_FILE_STDERR);
That way all tests using the driver would dump failures to the console, much
like they would on a *nix system. Is there any reason to _not_ do this?
Travis
--
View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r616003----stdcxx-branches-4.2.x-tests-utilities-20.temp.buffer.cpp-tp15144552p15153678.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, January 29, 2008 6:36 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: svn commit: r616003 -
>> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>>
> [...]
>>> I meant that it's not possible to know when we should
>> abort and when
>>> only print the message.
>> How about aborting on errors and assertions (e.g., by calling
>> rw_fatal()) and continuing on warnings (and calling rw_warn())?
>
> Maybe it's reasonable for the _CRT_ASSERT reports, but, for example,
> the _CRT_ERROR report is issued from abort() function. I'm not sure if
> we
> can invoke rw_fatal() from abort() :-)
Yeah, that might get us into an infinite loop. So it sounds like
on Windows we need to call whatever abort() calls after invoking
the hook. I.e., the observable behavior (from the POV of another
process) should be the same WRT exit status, etc.
Martin
>
> Farid.
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Travis Vitek <Tr...@roguewave.com>.
>Farid Zaripov wrote:
>
>> Martin Sebor wrote:
>>
>[...]
>> > I meant that it's not possible to know when we should
>> abort and when
>> > only print the message.
>>
>> How about aborting on errors and assertions (e.g., by calling
>> rw_fatal()) and continuing on warnings (and calling rw_warn())?
>
> Maybe it's reasonable for the _CRT_ASSERT reports, but, for example,
>the _CRT_ERROR report is issued from abort() function. I'm not sure if
>we
>can invoke rw_fatal() from abort() :-)
You should be able to, though it probably isn't a very good idea. It
just does a longjmp back out of the test.
I think there are a bigger questions that we should be asking ourselves.
Is windows the only platform that provides a debug version of the C
library? I don't know of any other platform that does, but I could be
very wrong.
If other platforms have a debug C library, do those C library
implementations abort() [or assert()] internally when something is
wrong. If they do, what is the behavior?
Should we really be translating crt warnings/errors/assertions to test
warnings/errors/assertions? I think the answer to this question is no.
It seems that this makes windows even more different than any other
platform. We don't attempt to report errors with rw_fatal() when the
system calls abort() on any other platform I'm familiar with.
Travis
>
>Farid.
>
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, January 29, 2008 6:36 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r616003 -
> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>
[...]
> > I meant that it's not possible to know when we should
> abort and when
> > only print the message.
>
> How about aborting on errors and assertions (e.g., by calling
> rw_fatal()) and continuing on warnings (and calling rw_warn())?
Maybe it's reasonable for the _CRT_ASSERT reports, but, for example,
the _CRT_ERROR report is issued from abort() function. I'm not sure if
we
can invoke rw_fatal() from abort() :-)
Farid.
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, January 29, 2008 6:27 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: svn commit: r616003 -
>> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>>
>> Farid Zaripov wrote:
>>>> -----Original Message-----
>>>> From: Martin Sebor [mailto:sebor@roguewave.com]
>>>> Sent: Tuesday, January 29, 2008 5:56 PM
>>>> To: dev@stdcxx.apache.org
>>>> Subject: Re: svn commit: r616003 -
>>>> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>>>>
>>>> Farid Zaripov wrote:
>>>>> Earlier
>>>>>
>> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.
>>>>> ht
>>>>> ml)
>>>>> I proposed to convert MSVC CRT debug reports along with invalid
>>>>> parameter checking reports to the rw_xxx() reports.
>>>> I (vaguely) remember discussing this. For the memory
>> errors, I thing
>>>> rw_error() or even rw_fatal() makes sense.
>>> The problem is that these reports may come from different
>> places of
>>> MSVC CRT and we couldn't to know what the real reason of concrete
>>> report. We get the only the report severity (error, assertion,
>>> warning) and the report text.
>>>
>>>>> Or we can just print the report message into stderr, to
>> not count
>>>>> these reports as other usual rw_errors and rw_asserts.
>>>> That would be another option. Although we should probably abort on
>>>> memory corruption errors.
>>> Unfortunately, it's not possible :(
>> Wouldn't the _CrtSetReportHook() function work?
>> http://msdn2.microsoft.com/en-us/library/0yysf5e6(VS.80).aspx
>
> I meant that it's not possible to know when we should abort and when
> only print the message.
How about aborting on errors and assertions (e.g., by calling
rw_fatal()) and continuing on warnings (and calling rw_warn())?
Martin
>
> Farid.
>
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, January 29, 2008 6:27 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r616003 -
> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:sebor@roguewave.com]
> >> Sent: Tuesday, January 29, 2008 5:56 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: svn commit: r616003 -
> >> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
> >>
> >> Farid Zaripov wrote:
> >>> Earlier
> >>>
> >>
> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.
> >>> ht
> >>> ml)
> >>> I proposed to convert MSVC CRT debug reports along with invalid
> >>> parameter checking reports to the rw_xxx() reports.
> >> I (vaguely) remember discussing this. For the memory
> errors, I thing
> >> rw_error() or even rw_fatal() makes sense.
> >
> > The problem is that these reports may come from different
> places of
> > MSVC CRT and we couldn't to know what the real reason of concrete
> > report. We get the only the report severity (error, assertion,
> > warning) and the report text.
> >
> >>> Or we can just print the report message into stderr, to
> not count
> >>> these reports as other usual rw_errors and rw_asserts.
> >> That would be another option. Although we should probably abort on
> >> memory corruption errors.
> >
> > Unfortunately, it's not possible :(
>
> Wouldn't the _CrtSetReportHook() function work?
> http://msdn2.microsoft.com/en-us/library/0yysf5e6(VS.80).aspx
I meant that it's not possible to know when we should abort and when
only print the message.
Farid.
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, January 29, 2008 5:56 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: svn commit: r616003 -
>> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>>
>> Farid Zaripov wrote:
>>> Earlier
>>>
>> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.
>>> ht
>>> ml)
>>> I proposed to convert MSVC CRT debug reports along with invalid
>>> parameter checking reports to the rw_xxx() reports.
>> I (vaguely) remember discussing this. For the memory errors,
>> I thing rw_error() or even rw_fatal() makes sense.
>
> The problem is that these reports may come from different places of
> MSVC CRT
> and we couldn't to know what the real reason of concrete report. We get
> the only
> the report severity (error, assertion, warning) and the report text.
>
>>> Or we can just print the report message into stderr, to not count
>>> these reports as other usual rw_errors and rw_asserts.
>> That would be another option. Although we should probably
>> abort on memory corruption errors.
>
> Unfortunately, it's not possible :(
Wouldn't the _CrtSetReportHook() function work?
http://msdn2.microsoft.com/en-us/library/0yysf5e6(VS.80).aspx
Martin
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, January 29, 2008 5:56 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r616003 -
> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>
> Farid Zaripov wrote:
> > Earlier
> >
> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.
> > ht
> > ml)
> > I proposed to convert MSVC CRT debug reports along with invalid
> > parameter checking reports to the rw_xxx() reports.
>
> I (vaguely) remember discussing this. For the memory errors,
> I thing rw_error() or even rw_fatal() makes sense.
The problem is that these reports may come from different places of
MSVC CRT
and we couldn't to know what the real reason of concrete report. We get
the only
the report severity (error, assertion, warning) and the report text.
> > Or we can just print the report message into stderr, to not count
> > these reports as other usual rw_errors and rw_asserts.
>
> That would be another option. Although we should probably
> abort on memory corruption errors.
Unfortunately, it's not possible :(
Farid.
Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, January 28, 2008 10:26 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: svn commit: r616003 -
>> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>>
>> Should we do this in <rw_new.h> (or new.cpp, on the first
>> call to operator new or operator delete) instead?
>
> Earlier
> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.ht
> ml)
> I proposed to convert MSVC CRT debug reports along with invalid
> parameter checking
> reports to the rw_xxx() reports.
I (vaguely) remember discussing this. For the memory errors,
I thing rw_error() or even rw_fatal() makes sense.
>
> Or we can just print the report message into stderr, to not count
> these reports
> as other usual rw_errors and rw_asserts.
That would be another option. Although we should probably
abort on memory corruption errors.
Martin
>
> Farid.
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, January 28, 2008 10:26 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r616003 -
> /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
>
> Should we do this in <rw_new.h> (or new.cpp, on the first
> call to operator new or operator delete) instead?
Earlier
(http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.ht
ml)
I proposed to convert MSVC CRT debug reports along with invalid
parameter checking
reports to the rw_xxx() reports.
Or we can just print the report message into stderr, to not count
these reports
as other usual rw_errors and rw_asserts.
Farid.