Could not break into gdb debugger when facing unexpected exception

[hiiwave]

Description

It's in fact the same issue as #586, where unexpected exceptions in the tests don't break into the gdb debugger with arguments -b --break. According to @horenmar at #418, it should have been implemented in commits b634e59, 25d0177, e1c4a4b. However it still does not work as expected.

Steps to reproduce

Follow the same steps in #586, the test reproducing this is as follows:

#define CATCH_CONFIG_MAIN
#include "catch.hpp"

TEST_CASE("exception") { throw "nobody expects the Spanish inquisition"; }

By compiling and running it under gdb:

g++ -g -std=c++0x tst.cpp && gdb --args ./a.out -b
Reading symbols from ./a.out...done.
(gdb) r
Starting program: a.out -b

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.out is a Catch v2.0.0-develop.4 host application.
Run with -? for options

-------------------------------------------------------------------------------
exception
-------------------------------------------------------------------------------
tst.cpp:4
...............................................................................

tst.cpp:4: FAILED:
due to unexpected exception with message:
  nobody expects the Spanish inquisition

===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed

the expected SIGTRAP doesn't happen.

Extra information

• Catch version: v2.0.0-develop.4 (also tried the single-header version on master)
• Operating System: Ubuntu 16.04
• Compiler+version: gcc version 5.4.0 (also tried clang version 3.8.0-2ubuntu4)

[horenmar]

So far, breaking into debugger happens only for failed assertions. This means that this

#define CATCH_CONFIG_MAIN
#include "catch.hpp"

int throws() {
    throw 1;
    return 1;
}

TEST_CASE("A") {
    REQUIRE(throws() == 2);
}

will break on the exception*, but your original code won't.

Looking over #586, it is a separate issue from the one closed by me, but since it was closed by its creator back in 2016, I never even noticed it existing. I'll take a look at what it would take to implement this for unexpected exceptions outside of assertions, but the usual caveat emptor applies: the backlog of potential features is much bigger than the amount of available time.

* Actually on the assertion failure

[hiiwave]

I see. It's my carelessness that I didn't notice that #586 was indeed a separate issue from #418. Hence so far I think the best way to debug with unexpected exception would be using catch throw in gdb itself. Thank you really much for your concern.

[philsquared]

@hiiwave does this conclude this issue for you?

[hiiwave]

I would say it's still preferable if breaking into debugger -b in Catch supports unexpected exceptions. Since the use of catch throw command in gdb has some side effects including that it also breaks at caught exceptions. @horenmar had clarified me that it's not a bug report but instead a feature request.

[ax3l]

I would love to use this feature as well. In my case, I am refactoring a larger code base with existing unit tests. When testing the result, exceptions from the library itself are thrown in the tests which I would like to debug in gdb by breaking into it and investigating the current backtrace.

Unfortunately, Catch2 does not break with -a -b at these points and throws me back to printf debugging.

[ax3l]

A current work-around with gdb can be to set breakpoints on all throws and iterate to the actual unexpected throw:

gdb --args ./CatchTest -a -b
(gdb) catch throw
(gdb) run

[tankorsmash]

That's a bummer. I'm on VS2013 and I'd love to be able to break on exceptions. I've got a std::out_of_range that I'd love to be able to break on.

[hsdk123]

I'm currently on VS2019 - would also love to have this as an option.

[mika-fischer]

I'd also like to see this. Otherwise it's unnecessarily difficult to unexpected exceptions.

[prat0088]

I will be changing testing frameworks because of this. It makes it unnecessarily very difficult to debug unexpected exceptions.

[jdumas]

Is there any chance to see this feature implemented in a future version of Catch2? I've been hitting this limitation a couple of times, and it would really help debugging for sure.

[ziereis]

how is this still not a thing? very disappointing