[BOOST_ASSERT] any one against improving debug support?
Hi, The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Does anyone object to defining it like this in <boost/assert.hpp> #if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif ? -Thorsten
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Agreed.
Does anyone object to defining it like this in <boost/assert.hpp>
#if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif
I'm very happy with this change.
Thorsten Ottosen:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point.
Does anyone object to defining it like this in <boost/assert.hpp>
#if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif
I'm not sure I understand. BOOST_ASSERT is just assert by default, right? assert does trigger a breakpoint by default, right? Boost.Test intentionally disables the assert breakpoint by default so that it can fail the test case and not require human intervention, right? What am I missing?
Peter Dimov skrev:
Thorsten Ottosen:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point.
Does anyone object to defining it like this in <boost/assert.hpp>
#if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif
I'm not sure I understand. BOOST_ASSERT is just assert by default, right?
Right.
assert does trigger a breakpoint by default, right?
Right. Here's visual C++ definition: #define assert(_Expression) (void)( (!!(_Expression)) || (_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
Boost.Test intentionally disables the assert breakpoint by default so that it can fail the test case and not require human intervention, right? What am I missing?
The break-point inserted by _ASSERT and _ASSERTE really causes the debugger to stop no matter what (via a asm { int 3; } instruction. The run from outside the debugger continues to run the test-cases. I've atatched by current defintion of <boost/assert.hpp>. Any objections to moving it to trunk? -Thorsten
Peter Dimov skrev:
Thorsten Ottosen:
Any objections to moving it to trunk?
Yes. I do not support infighting between Boost libraries. If you have a problem with Boost.Test's behavior, BOOST_ASSERT is not the proper vehicle to express it.
There is another reason that _ASSERTE is better. It allows you to ignore the assertions and continue execution in the debugger. -Thorsten
Thorsten Ottosen wrote:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point.
Use --catch_system_errors=no on the command line or testing.arg="--catch_system_errors=no" if you are using Boost.Build.
Ilya Sokolov skrev:
Thorsten Ottosen wrote:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point.
Use --catch_system_errors=no on the command line or testing.arg="--catch_system_errors=no" if you are using Boost.Build.
yeah, but it is pain to do this all the time. It's a good default for Boost's regression testing, but a poor default for ordinary unit-testing. -Thorsten
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
Ilya Sokolov skrev:
Thorsten Ottosen wrote:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point.
Use --catch_system_errors=no on the command line or testing.arg="--catch_system_errors=no" if you are using Boost.Build.
yeah, but it is pain to do this all the time. It's a good default for Boost's regression testing, but a poor default for ordinary unit-testing.
1. You can use environment variable to enforce desirable behavior all the time without your involvement. 2. In debugger (when it matters IMO) the break point is triggered regardless. If it's not the case it might be an issue. 3. I personally believe this is better way to report this error condition then test module is executed from command line. If I need to run in debugger I can always do this. 4. There is command line argument (auto_start_dbg) which should attach debugger automatically at the point of failure (instead of reporting error and aborting test module). It does not works for all debuggers yet, but it works very well on NT. Gennadiy
Gennadiy Rozental skrev:
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
Ilya Sokolov skrev:
Thorsten Ottosen wrote:
Hi,
The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Use --catch_system_errors=no on the command line or testing.arg="--catch_system_errors=no" if you are using Boost.Build. yeah, but it is pain to do this all the time. It's a good default for Boost's regression testing, but a poor default for ordinary unit-testing.
1. You can use environment variable to enforce desirable behavior all the time without your involvement.
I have defined BOOST_TEST_CATCH_SYSTEM_ERRORS to no, but no luck getting it to work.
2. In debugger (when it matters IMO) the break point is triggered regardless. If it's not the case it might be an issue.
Not for me.
3. I personally believe this is better way to report this error condition then test module is executed from command line. If I need to run in debugger I can always do this.
4. There is command line argument (auto_start_dbg) which should attach debugger automatically at the point of failure (instead of reporting error and aborting test module). It does not works for all debuggers yet, but it works very well on NT.
NT? I have defined BOOST_TEST_AUTO_START_DBG to yes. Not working for me. -Thorsten
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
1. You can use environment variable to enforce desirable behavior all the time without your involvement.
I have defined BOOST_TEST_CATCH_SYSTEM_ERRORS to no, but no luck getting it to work.
I found and fixed bug in execution monitor, which did not restore C Runtime report hook. Checked into trunk.
2. In debugger (when it matters IMO) the break point is triggered regardless. If it's not the case it might be an issue.
Not for me.
This scenario worked for me fine (even before fix). Gennadiy
Gennadiy Rozental skrev:
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
1. You can use environment variable to enforce desirable behavior all the time without your involvement. I have defined BOOST_TEST_CATCH_SYSTEM_ERRORS to no, but no luck getting it to work.
I found and fixed bug in execution monitor, which did not restore C Runtime report hook. Checked into trunk.
This made a difference. Thanks. I do get this warning when compiling: d:\boost\trunk\boost\test\impl\execution_monitor.ipp(1124) : warning C4701: potentially uninitialized local variable 'old_crt_hook' used I'm still not able to auto start the debugger, though. -Thorsten
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
Gennadiy Rozental skrev:
Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
1. You can use environment variable to enforce desirable behavior all the time without your involvement. I have defined BOOST_TEST_CATCH_SYSTEM_ERRORS to no, but no luck getting it to work.
I found and fixed bug in execution monitor, which did not restore C Runtime report hook. Checked into trunk.
This made a difference. Thanks. I do get this warning when compiling:
d:\boost\trunk\boost\test\impl\execution_monitor.ipp(1124) : warning C4701: potentially uninitialized local variable 'old_crt_hook' used
Thanks. I default constructed it.
I'm still not able to auto start the debugger, though.
Unfortunately, it appears, you can't use it with msvc asserts. They look internally like c++ exceptions and code never reaches appropriate if, even if you tell it to catch system errors. But you can try it with any other type of failure. Gennadiy
participants (5)
-
Craig Henderson -
Gennadiy Rozental -
Ilya Sokolov -
Peter Dimov -
Thorsten Ottosen