Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <480DF406.6050200@roguewave.com>
Date: Tue, 22 Apr 2008 08:19:50 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
References: <20080415064419.5101D1A9838@eris.apache.org>
 <CFFDD219128FD94FB4F92B99F52D0A499AA80D@exchmail01.Blue.Roguewave.Com>
 <7BDB2168BEAEF14C98F1901FD2DE64383C3EB6@epmsa009.minsk.epam.com>
 <CFFDD219128FD94FB4F92B99F52D0A49465B4E@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49465B4F@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49465B4F@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I agree that the purpose of --verbose is to provide additional
informational detail about what's being tested, not to increase
the strictness of the test. Adding a new option to enable
expensive memory checks sounds like the right approach to me.

Martin

Travis Vitek wrote:
> I managed to prematurely send that last message. Here is the completed response 
> 
> 
> 
>> Farid Zaripov wrote:
>>
>> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
>> To: dev@stdcxx.apache.org
>> Subject: RE: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
>>
>>>>       * tests/src/driver.cpp [_MSC_VER] (_rw_opt_verbose):
>>>>       Turn on checking the memory at every allocation and
>>>>       deallocation in verbose mode.
>>> Perhaps this should be put into its own routine option. I
>>> believe that this memory checking can slow things down quite
>>> a bit, and I'd like to avoid that overhead when doing verbose
>>> checking.
>>  And how often you're doing verbose checking? :)
> 
> I actually use it occasionally to verify that any rw_assert() calls I add will display correctly in verbose mode, but that isn't really the point.
> 
>> I see that
>> the only difference between the verbose and non-verbose modes
>> is printing the description (diag_msgs[].desc) in diag messages.
> 
> The definition of verbose is 'to use more words than are necessary'. Typically verbose mode for a program enables additional output but it doesn't change the behavior of the program in other ways.
> 
>> So I thought that --verbose option is used very rarely at this
>> time and the name of this option is corresponding to added
>> actions - verbose checking the using of the heap memory :)
> 
> Just because we don't use the option frequently isn't a good reason misuse it. At home we don't use our fine china dinnerware more than once a year, but I wouldn't dare use the gravy boat as an oil pan.
> 
>>>>       (_rw_opt_compat): Disable MSVC debug popup's in compat mode.
>>> According to some conversation we had with Martin last week,
>>> this should have been enabled all the time. If this is the case,
>>> maybe this code should be moved to rw_vtest() to make that happen?
>>  Why? Personally I found the debug MSVC popups very useful in
>> debugging.You can't miss the debug message because you have to
>> press some button in message box to close it.
> 
> Oh, I agree. They make it difficult to not notice a failure, especially when running the tests from the command line.
> 
>> And you need press the only one button ("Retry") to launch and
>> attach the debugger and see the source file on failing line with
>> call stack. If they are will be disabled all the time, you will
>> need scan the program output for the debug messages and then
>> wast some time to find the failing line in source code...
> 
> Well, now I have two more problems with this change. First this change disables the window for CRT errors only. It should probably do the same for the gpfault error box via a call to SetErrorMode(). Second, it sends the messages only to the debugger output window. I think we should be sending them stderr also so that we can see the messages in the output spew. Otherwise it would be _very_ easy to overlook these types of errors.
> 
>   _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
>   _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
>   _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
>   _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
>   _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
>   _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
> 
>> Of course we can enable these popups by adding a new program
>> option, but I launching the tests from IDE most of time and
>> it's not convinient to specify the program options manually
>> for every test (but I found that I can use the RWSTD_TESTOPTS
>> environment variable for this :) ).
> 
> If you're launching an individual test from the IDE with F5 or CTRL+F5 you would have to specify the --compat command line option (or the hypothetical --no-popups option) somewhere to disable the CRT error dialog, so this should not be a problem. The CRT error dialogs should continue appear as it always has in this situation.
> 
> If you are using the runtests project from within the IDE, I believe that it sets the --compat flag automatically for each executable that is ran from runall.wsh. So you would not see the CRT error messages and you would need to find a way to disable the command line option then.
> 
> So what I'm saying here is that we should consider adding a new option --no-popups that calls _CrtSetReportMode(), _CrtSetReportFile() and SetDebugMode(). That option should probably be passed to the exec utility to pass on to each test when running the nightly builds. Adding this option should have no impact on the behavior you experience when running tests from the IDE today.
> 
> Travis
>