Hi Thorsten, While the test makes no sense it is often desirable to run all of the other tests and simply mark this failure. If the behaviour were to hang in the debugger this would not work well for the automated builds although it would be convenient for us developers when debugging. I am normally compiling directly with Visual Studio, but this is not an issue. You can start an executable under the debugger anyhow. If this is inconvenient then you will need to find an alternative means for switching the assertion behaviour, such as a command-line switch. I think this was added to the unit test framework in version 1.30.2 as --catch_system_errors="no". Otherwise there is the environment variable BOOST_TEST_CATCH_SYSTEM_ERRORS which does the same job. The reason the unit tests do not crash and exhibit the default just-in-time debugger behaviour is because of the unit test program execution monitor. The code that effects this is in boost/test/impl/execution_monitor.ipp. You will notice that there is code in execution_monitor::execute to configure the catch_system_errors flag to false if a debugger is already attached. Since this doesn't do quite what you want, you will probably need to modify the _set_se_translator behaviour. The simplest thing to do would probably be to turn off the SEH translator by avoiding the call while you are debugging. Best Wishes, Neil Groves -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: 09 December 2007 16:40 To: boost@lists.boost.org Subject: Re: [boost] [test] integration with debugger Neil Groves skrev:

Hi Thorsten,

I normally place soft breakpoint in the code that announces the test failure and walk the call stack.

You are compiling directly with visual studio then? I'm usign bjam + slickedit as my enviroenment.

Alternatively you can use the IsDebuggerPresent() call combined with DebugBreak as a Windows only modification to the assertions. This only causes a debug break if a developer has attached a local debugger. The automated unit test execution is unaffected.

I would prefer if the the unit-test itself could be debugged. The unite-test makes no sense if there is a serious assertion triggering somewhere.

I'm a bit annoyed that I don't break into the debugger, when an assertion triggers.

When I write a normal program, it crashes and allows me to debug it...with boost.test, the behavior has been modified somehow. -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Neil Groves skrev:

Thorsten,

I have been looking into this a little more and have discovered that there is also a --auto_start_dbg option. That might do exactly what you asked for.

I think it might be. I could run this from the command line, and also with the run-command in bjam, but not with the unit-test rule. (In fact, the document pages that explains this is empty). -Thorsten

Gennadiy Rozental skrev:

"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:475C5C55.1080600@dezide.com...

...

Neil Groves skrev:

...

Thorsten,

I have been looking into this a little more and have discovered that there is also a --auto_start_dbg option. That might do exactly what you asked for. I think it might be. I could run this from the command line, and also with the run-command in bjam, but not with the unit-test rule. (In fact, the document pages that explains this is empty).

Now I am confised. You mean you can;t make Boost.Build pass the command line argument to your test module, right?

Boost.Build list might be a better place to get a help with this.

I can try that. Have you ever passed arguments to Boost.Test's unit-test framework with Boost.Build? AFAICT, it is not possible to give these arguments to the "unit-test" rule.

Please let me know, if you still expirience any problemms with Boost.Test

I have played a little with the assertions also. I found that doing #if (BOOST_MSVC >= 1400) #include <crtdbg.h> #endif #if (BOOST_MSVC >= 1400) #define DEZIDE_ASSERT _ASSERT #else #define DEZIDE_ASSERT BOOST_ASSERT #endif also improves the situation quite a bit. With the normal BOOST_ASSERT(), the program would not break immediately at the point of the assertion, which was a major annoyance to me. Perhaps we should consider upgrading BOOST_ASSERT? -Thorsten

"Neil Groves" <neil@grovescomputing.com> wrote in message news:000001c83a7b$7a2ac1b0$6e804510$@com...

Hi Thorsten,

I normally place soft breakpoint in the code that announces the test failure and walk the call stack.

Alternatively you can use the IsDebuggerPresent() call combined with DebugBreak as a Windows only modification to the assertions. This only causes a debug break if a developer has attached a local debugger. The automated unit test execution is unaffected.

See: http://msdn2.microsoft.com/en-us/library/ms680345.aspx for IsDebuggerPresent()

This is what bost.Test doing already. Gennadiy