Re: [boost] [test] integration with debugger

From: Neil Groves (neil_at_[hidden])
Date: 2007-12-09 12:46:10

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_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Thorsten Ottosen
Sent: 09 December 2007 16:40
To: boost_at_[hidden]
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