stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject [PING] purpose of --verbose option (was: Re: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp)
Date Tue, 29 Apr 2008 02:26:43 GMT
This shouldn't get forgotten. Farid, unless you have an objection
to Travis' suggestion to add the memory checking under a separate
option, can you please make the change?

Martin Sebor wrote:
> 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
>>
> 
> 


Mime
View raw message