Aborting on Boost.Test check failure

Jeremiah Willcock

4 Mar 2012 4 Mar '12

7:30 p.m.

Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb. -- Jeremiah Willcock

Show replies by date

Gennadiy Rozental

5 Mar 5 Mar

4:07 p.m.

Jeremiah Willcock writes:

...

Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw. Gennadiy

Jeremiah Willcock

4:22 p.m.

On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

...

Jeremiah Willcock writes:

...
Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw.

Does that mean needing to change all of the tests to use that? Also, what about doing that in a program that throws (and catches) other exceptions not related to test failures? -- Jeremiah Willcock

Ovanes Markarian

7:38 p.m.

On Mon, Mar 5, 2012 at 5:22 PM, Jeremiah Willcock wrote:

...

On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

Jeremiah Willcock writes:

...
...
Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw.

Does that mean needing to change all of the tests to use that? Also, what about doing that in a program that throws (and catches) other exceptions not related to test failures?

Is using of GDB catchpoints an option for you ( http://www.delorie.com/gnu/docs/gdb/gdb_31.html)? Or would you like to automate it somehow? Boost Test offers to start a debugger when an exception is raised, I never tried it out, but seems to be an interesting runtime-option (auto_start_dbg): http://www.boost.org/doc/libs/1_46_1/libs/test/doc/html/utf/user-guide/runti.... Is it going to work with gdb as well? Best Regards, Ovanes

Jeremiah Willcock

8:21 p.m.

On Mon, 5 Mar 2012, Ovanes Markarian wrote:

...

On Mon, Mar 5, 2012 at 5:22 PM, Jeremiah Willcock wrote: On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

Jeremiah Willcock writes:

Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw.

Does that mean needing to change all of the tests to use that? Also, what about doing that in a program that throws (and catches) other exceptions not related to test failures?

Is using of GDB catchpoints an option for you (http://www.delorie.com/gnu/docs/gdb/gdb_31.html)? Or would you like to automate it somehow? Boost Test offers to start a debugger when an exception is raised, I never tried it out, but seems to be an interesting runtime-option (auto_start_dbg): http://www.boost.org/doc/libs/1_46_1/libs/test/doc/html/utf/user-guide/runti.... Is it going to work with gdb as well?

Yes, as long as there are directions for what to do. The auto_start_dbg option didn't seem to work; it appears that option will only catch system errors, not test failures (at least from what I read in the documentation). -- Jeremiah Willcock

Gennadiy Rozental

11:03 p.m.

Jeremiah Willcock writes:

...

The auto_start_dbg option didn't seem to work; it appears that option will only catch system errors, not test failures (at least from what I read in the documentation).

Yes. auto_start_dbg will attach debugger at the point where SIGSEGV like event occurs. Gennadiy

Gennadiy Rozental

11:01 p.m.

Jeremiah Willcock writes:

...

On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

...
Jeremiah Willcock writes:

...
Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw.

Does that mean needing to change all of the tests to use that?

Yes.

...

Also, what about doing that in a program that throws (and catches) other exceptions not related to test failures?

They will interfere ;) Frankly i am not sure I understand the original incentive. Run the test without the debugger. It'll report the line number for the failure. Then just set a breakpoint at this line. This way you can actually debug into a failing call instead of looking at post-effect of failed validation inside the Boost.Test. Regards, Gennadiy

Jeremiah Willcock

11:15 p.m.

On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

...

Jeremiah Willcock writes:

...
On Mon, 5 Mar 2012, Gennadiy Rozental wrote:

...
Jeremiah Willcock writes:

...
Is there a way to force an abort() or some other kind of debugger-catchable event when a Boost.Test test case (such as a BOOST_CHECK) fails? Is there a function I can set a breakpoint on? I do not see anything like that in the documentation. I am running on Linux with gdb.

You can switch to BOOST_REQUIRE and catch throw.

Does that mean needing to change all of the tests to use that?

Yes.

That seems to be difficult to add to an existing test suite.

...

...
Also, what about doing that in a program that throws (and catches) other exceptions not related to test failures?

They will interfere ;)

Frankly i am not sure I understand the original incentive. Run the test without the debugger. It'll report the line number for the failure. Then just set a breakpoint at this line. This way you can actually debug into a failing call instead of looking at post-effect of failed validation inside the Boost.Test.

The code that I was working with uses a common test function that is called multiple times with different inputs, making it more difficult to breakpoint that single line. Is there a reason not to provide abort() or similar functionality? -- Jeremiah Willcock

Gennadiy Rozental

6 Mar 6 Mar

10:21 a.m.

Jeremiah Willcock writes:

...

The code that I was working with uses a common test function that is called multiple times with different inputs, making it more difficult to breakpoint that single line. Is there a reason not to provide abort() or similar functionality?

Trunk version of Boost.Test provides a better (IMO) solution to this problem: test context. Using that you can see which input causes assertion to fail. Gennadiy

Ovanes Markarian

11:34 a.m.

[...]

...

...
Frankly i am not sure I understand the original incentive. Run the test without the debugger. It'll report the line number for the failure. Then just set a breakpoint at this line. This way you can actually debug into a failing call instead of looking at post-effect of failed validation inside the Boost.Test.

The code that I was working with uses a common test function that is called multiple times with different inputs, making it more difficult to breakpoint that single line. Is there a reason not to provide abort() or similar functionality?

Just to offer you a quick workaround: you can raise a conditional signal "raise(SIGINT)". Running the app in the debugger will stop when the condition is reached. Regards, Ovanes

4773

Age (days ago)

4775

Last active (days ago)

List overview

Download

9 comments

3 participants

participants (3)

Gennadiy Rozental
Jeremiah Willcock
Ovanes Markarian