[test] runnning the debugger when an assertion fails

Hi Gennadiy, http://www.boost.org/libs/test/doc/usage/command_line.html states "If you got "memory access violation" message (or any other message indication fatal or system error) when you run you test, to get more information of error location add --catch_system_errors=no to the test run command line. Now run the test again and it will create a coredump you could analyze using you preferable debugger. Or run it under debugger in a first place and it will break at the point of failure." I tried adding --catch_system_errors=no to the run-command in bjam, and I tried specifying it manually on the command line. No luck. I'm using windows xp, and visual c++8. Is it not possible to break into the debugger from a unit-test? Thanks -Thorsten

Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
Hi Gennadiy,
http://www.boost.org/libs/test/doc/usage/command_line.html
states
"If you got "memory access violation" message (or any other message indication fatal or system error) when you run you test, to get more information of error location add --catch_system_errors=no to the test run command line. Now run the test again and it will create a coredump you could analyze using you preferable debugger. Or run it under debugger in a first place and it will break at the point of failure."
I tried adding --catch_system_errors=no to the run-command in bjam, and I tried specifying it manually on the command line. No luck.
Should work. I am not sure how to do it with bjam, but specifying the argument directly to the test invocation should do what you need.
I'm using windows xp, and visual c++8. Is it not possible to break into the debugger from a unit-test?
It should work. I nfact in develpment version in svn there is new CLA: --auto_run_dbg=[yes|no|debugger name], which should immediately attach debugger to the point of failure. You don't need to specify -- catch_system_errors in that case. Gennadiy
participants (2)
-
Gennadiy Rozental
-
Thorsten Ottosen