Crash on invalid pointer reference instead of Objective-C exception handling

[iamleeg]

I'm not really sure how to debug this (my C++ is not that strong), but it looks like the exception should be caught at the same level it's thrown:

$ gdb obj/classy-tests
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ............. done

(gdb) run
Starting program: /Users/leeg/Documents/Local Projects/classy/obj/classy-tests
Reading symbols for shared libraries ++++++++++++................................................................................................................................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff942fae8a in __cxxabiv1::__pbase_type_info::__do_catch ()
(gdb) bt

0 0x00007fff942fae8a in __cxxabiv1::__pbase_type_info::__do_catch ()

1 0x00007fff942f9e26 in get_adjusted_ptr ()

2 0x00007fff942f9a5b in __gxx_personality_v0 ()

3 0x00007fff937c891f in _Unwind_RaiseException ()

4 0x00007fff942fa1dc in __cxa_rethrow ()

5 0x000000010000b1fb in Catch::ExceptionTranslatorRegistry::translateActiveException (this=0x100419970) at catch_exception_translator_registry.hpp:44

6 0x000000010001135a in Catch::Runner::runCurrentTest (this=0x7fff7b3c20f0, redirectedCout=@0x474e5543432b2b00, redirectedCerr=@0x474e5543432b2b00) at catch_runner_impl.hpp:364

7 0x000000010001176a in Catch::Counts::operator- () at /Users/leeg/Documents/Local Projects/classy/Catch/include/internal/catch_totals.hpp:147

8 0x000000010001176a in Catch::Totals::operator- () at /Users/leeg/Documents/Local Projects/classy/Catch/include/internal/catch_totals.hpp:36

9 0x000000010001176a in Catch::Runner::runTest (this=0x7fff5fbfef80, testInfo=@0x7fff5fbfeef0) at catch_runner_impl.hpp:148

10 0x000000010000c08b in Catch::Runner::runAll (this=0x7fff5fbfef50, runHiddenTests=false) at catch_runner_impl.hpp:101

11 0x0000000100011b48 in Catch::Main (config=@0x7fff5fbfef80) at catch_runner.hpp:59

12 0x000000010001390b in Catch::Main (argc=5546480, argv=0x7fff5fbff730, config=@0x7fff5fbff558) at catch_runner.hpp:130

13 0x0000000100013973 in Catch::Main (argc=1606415704, argv=0x10054a1f0) at catch_runner.hpp:143

14 0x0000000100002edb in main (argc=1606415704, argv=0x10054a1f0) at catch_default_main.hpp:27

15 0x0000000100001ba4 in start ()

(gdb)

The exception is actually an Objective-C exception, which I can see if I take the code in my test out of a TEST_CASE and put it in main():

$ obj/classy-tests
2012-05-21 17:52:57.959 classy-tests[9489:b03] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Attempt to init component without a context. In -[WOComponent initWithContext:]'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff96d10f56 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8d35ed5e objc_exception_throw + 43
2 CoreFoundation 0x00007fff96d10d8a +[NSException raise:format:arguments:] + 106
3 CoreFoundation 0x00007fff96d10d14 +[NSException raise:format:] + 116
4 WebObjects 0x000000010fd09576 -[WOComponent initWithContext:] + 118
5 WebObjects 0x000000010fd06ae5 -[WOComponent init] + 53
6 classy-tests 0x000000010fcdbe89 main + 89
7 classy-tests 0x000000010fcdbe24 start + 52
)
terminate called throwing an exceptionAbort trap: 6

So it'd be great to catch Objective-C exceptions (which it looks like CATCH's C++ is capable of doing, at least on the new runtime where they use the same machinery), but then to describe them and mark the test as failed instead of dying :-)

[philsquared]

Hmmm... sounds like a reasonable conclusion.

I'll try and take a look shortly - thanks for raising this (pun intended).

[philsquared]

I've added support for catching Objective-C exceptions.
Would appreciate if you could try the latest with your example and see what it gives you?

[iamleeg]

Wait...the raise pun or the try pun? Anyway, it looks like it works; is the '0 test cases failed' output intentional (the assertion didn't fail because the test vomited before it got there)?

$ obj/classy-tests
[Started testing]
[Started group: 'test case run']

[Running: Main/basic]
classy-tests.mm:8: Unexpected exception with message: '@"Attempt to init component without a context. In -[WOComponent initWithContext:]"'
[End of group: 'test case run'. 0 test cases failed]

[Finished: 'Main/basic' 1 test case failed (1 assertion failed)]

[Testing completed. 1 test case failed (1 assertion failed)]

[philsquared]

Wait...the raise pun or the try pun?
You'll never know ;-)

As for the other issue. Yeah, I noticed that too as I was looking at your first issue. However I didn't think it was related (suspected it was to do with some other changes I made recently - a suspicion that proved correct) - so I didn't let that stop me from checking in.

I've now sorted the test count issue. It wasn't that the exception was preventing it from counting the failure - just that it was reporting them just before it has updated the totals.

Latest version checked in should fix that. I'm closing this issue now as your original issue is resolved