[Mac] Redo NSException handling, and generate better stacks for C++ exceptions.

[Mac] Redo NSException handling, and generate better stacks for C++ exceptions.

This introduces base::mac::CallWithEHFrame(), which will run a block in a
stack frame that is set up to stop searching for an exception handler when it
is reached. This is used to prevent a top-level exception handler, installed
in CFRunLoopRunSpecific(), from catching and rethrowing C++ exceptions. When
it does this, the resulting stack traces are not useful for triage purposes. By
stoping the search for an exception handler, the runtime will call
std::terminate directly from the throwing stack trace.

In addition, NSException handling is converted from swizzling the designated
initializer to an ObjC 2.0 exception preprocessor.

Some exceptions could still escape this mechanism, if they are thrown
without CallWithEHFrame() on the stack. This could happen if the exception
were thrown outside of the MessagePump's work sources or -sendEvent:. Possible
situations are things like the CFRunLoop block and Mach port callouts. This
shouldn't happen from Chromium code, so it would only affect system-thrown
exceptions. These exceptions would still be fatal, just with the less-useful
run loop stack.

To summarize: all uncaught exceptions are fatal one way or another. If the
exception isn't caught before it unwinds to CallWithEHFrame, the crash will have
an immediately actionable stack from the point of throw. If the exception is
caught by the run loop or some other top-level exception handler, the exception
will be rethrown and the crash stack will be less useful. In that case, if it's
an ObjC exception, a crash key will still record a trace from the point-of-
throw. Using try/catch is now unrestricted, and no special whitelist is
maintained to allow certain NSExceptions to be alloc/init'd.

BUG=503128
R=shess@chromium.org, thakis@chromium.org

Committed: https://crrev.com/73dc3d5a6345ddd43a1a54f06dd4058be8a9842b
Cr-Commit-Position: refs/heads/master@{#338332}

[Robert Sesek, 2015-06-26 00:05:50]

Patchset #1 (id:1) has been deleted

[Robert Sesek, 2015-06-26 19:25:57]

Patchset #1 (id:20001) has been deleted

[Robert Sesek, 2015-06-26 19:26:02]

Patchset #1 (id:40001) has been deleted

[Robert Sesek, 2015-06-29 16:38:56]

Patchset #1 (id:60001) has been deleted

[Robert Sesek, 2015-06-29 16:47:43]

rsesek@chromium.org changed reviewers:
+ shess@chromium.org, thakis@chromium.org

[Robert Sesek, 2015-06-29 17:01:42]

thakis: Please review.
shess: Would like your review when you return from OOO. I will address any
comments you have when you return.

[Scott Hess - ex-Googler, 2015-07-06 22:34:04]

I _think_ LGTM, because this is high voodoo beyond my membership level.  The
only bit I'm confident on is that +initialize is not guaranteed to be once-only.

As best I can recall, the overall goal is something like:
1) NSException caused by our code is fatal.
2) NSException by Cocoa with none of our code on the stack is allowed.
3) NSException which is explicitly caught is allowed.

For 1) is things like out-of-bounds access to an NSString or NSArray, even if
our code doesn't make the actual access, it's likely that our code asked a
question requiring such access, so we should just fix our code.

For 2) is things like the many random threads Cocoa starts on our behalf, as
long as Cocoa is explicitly ignoring the exceptions and not fixing the thrower,
there's not a lot we can do about it.

For 3) is cases like print or save panels with 3rd-party modules, where we may
be on the stack, but we are not in direct control of failures in the
implementation.  So we put an explicit try/catch in there to protect ourselves
against bad implementations in loadable modules.

So I think everything is covered, though I maybe don't fully understand how it
works.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame.h (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame.h:21: void BASE_EXPORT CallWithEHFrame(void
(^block)(void));
Most of the users of this are functions which take no parameters and return
nothing.  Basically exactly like the block.  How much overhead does a block add
in this case?  Also, as used would there be any benefit to constructing the
block once and re-using it?

I realize that it's entirely possible that this bit of overhead is trivial
relative to the rest.  On the other hand, it's all deeply embedded so it's
reasonable to work a little harder.  If that's even possible, though.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame_unittest.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame_unittest.mm:46: ASSERT_FALSE(saw_exception);
Should this code crash by failing this assertion, or should it crash at the
point of throwing the exception?  If it's the latter case, could the death
regexp be used to verify that it did _not_ get here?

https://codereview.chromium.org/1212093002/diff/80001/chrome/browser/chrome_b...
File chrome/browser/chrome_browser_application_mac.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:153:
&chrome_browser_application_mac::ExceptionPreprocessor);
Suggest checking the global before calling this, in case someone subclasses or
something.

[Robert Sesek, 2015-07-07 22:26:17]

On 2015/07/06 22:34:04, Scott Hess wrote:
> I _think_ LGTM, because this is high voodoo beyond my membership level.  The
> only bit I'm confident on is that +initialize is not guaranteed to be
once-only.
> 
> As best I can recall, the overall goal is something like:
> 1) NSException caused by our code is fatal.
> 2) NSException by Cocoa with none of our code on the stack is allowed.
> 3) NSException which is explicitly caught is allowed.
> 
> For 1) is things like out-of-bounds access to an NSString or NSArray, even if
> our code doesn't make the actual access, it's likely that our code asked a
> question requiring such access, so we should just fix our code.

Right. We almost never use @try/@catch, so these are fatal.

> For 2) is things like the many random threads Cocoa starts on our behalf, as
> long as Cocoa is explicitly ignoring the exceptions and not fixing the
thrower,
> there's not a lot we can do about it.

The exceception, if uncaught, will still be fatal. But the stack trace in the
crash report will be from the top-level exception handler. We'll still stuff the
throw backtrace in a crash key via the exception preprocessor, though.

> For 3) is cases like print or save panels with 3rd-party modules, where we may
> be on the stack, but we are not in direct control of failures in the
> implementation.  So we put an explicit try/catch in there to protect ourselves
> against bad implementations in loadable modules.

Right. Or presumably the third-party code raising the exception was intending to
catch it, but our existing fatalisation mechanism required us to add an explicit
allow.

> So I think everything is covered, though I maybe don't fully understand how it
> works.

Nope, I think you've got it :).

The TL;DR is all uncaught exceptions are fatal one way or another. If the
exception isn't caught before it hits CallWithEHFrame, the crash will have an
immediately actionable stack from the point of throw. If the exception is caught
by the run loop or some other top-level exception handler, the exception will be
rethrown and the crash stack will be less useful. In that case, if it's an ObjC
exception, we will still have a trace from the point-of-throw via the crash key.
Using try/catch is now fine and no special whitelist is maintained to allow
certain NSExceptions to be alloc/init'd.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame.h (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame.h:21: void BASE_EXPORT CallWithEHFrame(void
(^block)(void));
On 2015/07/06 22:34:04, Scott Hess wrote:
> Most of the users of this are functions which take no parameters and return
> nothing.  Basically exactly like the block.  How much overhead does a block
add
> in this case?  Also, as used would there be any benefit to constructing the
> block once and re-using it?
> 
> I realize that it's entirely possible that this bit of overhead is trivial
> relative to the rest.  On the other hand, it's all deeply embedded so it's
> reasonable to work a little harder.  If that's even possible, though.

The keyword here is "most", which is why I went with the block-based approach.
The issue is the one or two places where the arity differs, and that then
requires a whole new CallWithEHFrame just for that, exploding the size of the .S
file.

The blocks should be relatively low overhead. Blocks are basically a
compiler-generated function and some special memory space for any captured
variables (where this memory lives depends on the type of block). In this case,
the blocks should be "stack blocks", meaning the block storage space is just a
little extra allocation on the stack. That should be relatively negligble. I can
probably microbench this if you'd like, but I was just going to rely on Telemtry
to make sure that it's OK.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame_unittest.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame_unittest.mm:46: ASSERT_FALSE(saw_exception);
On 2015/07/06 22:34:04, Scott Hess wrote:
> Should this code crash by failing this assertion, or should it crash at the
> point of throwing the exception?  If it's the latter case, could the death
> regexp be used to verify that it did _not_ get here?

It should crash by throwing the excpetion.

https://codereview.chromium.org/1212093002/diff/80001/chrome/browser/chrome_b...
File chrome/browser/chrome_browser_application_mac.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:153:
&chrome_browser_application_mac::ExceptionPreprocessor);
On 2015/07/06 22:34:04, Scott Hess wrote:
> Suggest checking the global before calling this, in case someone subclasses or
> something.

Done.

[Scott Hess - ex-Googler, 2015-07-07 22:34:31]

Still LGTM.  It's plausible to me that my comment on the test is either
mis-guided or impossible to deal with reliably.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame.h (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame.h:21: void BASE_EXPORT CallWithEHFrame(void
(^block)(void));
On 2015/07/07 22:26:17, Robert Sesek wrote:
> On 2015/07/06 22:34:04, Scott Hess wrote:
> > Most of the users of this are functions which take no parameters and return
> > nothing.  Basically exactly like the block.  How much overhead does a block
> add
> > in this case?  Also, as used would there be any benefit to constructing the
> > block once and re-using it?
> > 
> > I realize that it's entirely possible that this bit of overhead is trivial
> > relative to the rest.  On the other hand, it's all deeply embedded so it's
> > reasonable to work a little harder.  If that's even possible, though.
> 
> The keyword here is "most", which is why I went with the block-based approach.
> The issue is the one or two places where the arity differs, and that then
> requires a whole new CallWithEHFrame just for that, exploding the size of the
.S
> file.
> 
> The blocks should be relatively low overhead. Blocks are basically a
> compiler-generated function and some special memory space for any captured
> variables (where this memory lives depends on the type of block). In this
case,
> the blocks should be "stack blocks", meaning the block storage space is just a
> little extra allocation on the stack. That should be relatively negligble. I
can
> probably microbench this if you'd like, but I was just going to rely on
Telemtry
> to make sure that it's OK.

OK.  Mostly performance was the only thing I could legitimately noodle about. 
And Cocoa probably builds blocks like there's no tomorrow anyhow.

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame_unittest.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame_unittest.mm:46: ASSERT_FALSE(saw_exception);
On 2015/07/07 22:26:17, Robert Sesek wrote:
> On 2015/07/06 22:34:04, Scott Hess wrote:
> > Should this code crash by failing this assertion, or should it crash at the
> > point of throwing the exception?  If it's the latter case, could the death
> > regexp be used to verify that it did _not_ get here?
> 
> It should crash by throwing the excpetion.

To be clear, what I meant was that this snippet can fail with a crash in two
places, so I was wondering if there were any way to have the death test verify
that it was the right place and not the wrong place.  Perhaps the
exception-not-handled termination output has something unique-ish that the
regexp can match.

[Robert Sesek, 2015-07-07 22:35:55]

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
File base/mac/call_with_eh_frame_unittest.mm (right):

https://codereview.chromium.org/1212093002/diff/80001/base/mac/call_with_eh_f...
base/mac/call_with_eh_frame_unittest.mm:46: ASSERT_FALSE(saw_exception);
On 2015/07/07 22:34:31, Scott Hess wrote:
> On 2015/07/07 22:26:17, Robert Sesek wrote:
> > On 2015/07/06 22:34:04, Scott Hess wrote:
> > > Should this code crash by failing this assertion, or should it crash at
the
> > > point of throwing the exception?  If it's the latter case, could the death
> > > regexp be used to verify that it did _not_ get here?
> > 
> > It should crash by throwing the excpetion.
> 
> To be clear, what I meant was that this snippet can fail with a crash in two
> places, so I was wondering if there were any way to have the death test verify
> that it was the right place and not the wrong place.  Perhaps the
> exception-not-handled termination output has something unique-ish that the
> regexp can match.

No, I don't think so. One is a crash and the other is an assertion failure,
which just changes the exit code from 0 to 1. But I also can't seem to get any
assertion failure to print out a message that I could test for with the
EXPECT_DEATH string matcher.

[Robert Sesek, 2015-07-08 16:23:19]

Patchset #3 (id:120001) has been deleted

[Robert Sesek, 2015-07-08 16:49:57]

thakis: PTAL

[Nico, 2015-07-09 19:36:22]

there are no dumb questions there are no dumb questions there are no dumb
questions

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
File base/mac/call_with_eh_frame_asm.S (right):

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:15: .cfi_startproc
After starting at this for a bit, isn't this morally identical to

  CallWithEHFrame(void (^block)()) {
    @try {
      block();
    } @catch (id type) {
      CHECK(false);
    }
  }

?

[Robert Sesek, 2015-07-09 20:16:43]

On 2015/07/09 19:36:22, Nico wrote:
> there are no dumb questions there are no dumb questions there are no dumb
> questions

:) this is all quite subtle

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
File base/mac/call_with_eh_frame_asm.S (right):

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:15: .cfi_startproc
On 2015/07/09 19:36:22, Nico wrote:
> After starting at this for a bit, isn't this morally identical to
> 
>   CallWithEHFrame(void (^block)()) {
>     @try {
>       block();
>     } @catch (id type) {
>       CHECK(false);
>     }
>   }
> 
> ?

It's close, but no. That would cause a crash with a stacktrace only showing
CallWithEHFrame. By telling the ABI to stop searching for an exception handler,
it effectively re-winds the stack back up and calls std::terminate from the
place where |throw| was originally called. If you want the gory details, see the
linked bug.

[Scott Hess - ex-Googler, 2015-07-09 20:21:40]

On 2015/07/09 20:16:43, Robert Sesek wrote:
> On 2015/07/09 19:36:22, Nico wrote:
> > there are no dumb questions there are no dumb questions there are no dumb
> > questions
> 
> :) this is all quite subtle
> 
>
https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
> File base/mac/call_with_eh_frame_asm.S (right):
> 
>
https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
> base/mac/call_with_eh_frame_asm.S:15: .cfi_startproc
> On 2015/07/09 19:36:22, Nico wrote:
> > After starting at this for a bit, isn't this morally identical to
> > 
> >   CallWithEHFrame(void (^block)()) {
> >     @try {
> >       block();
> >     } @catch (id type) {
> >       CHECK(false);
> >     }
> >   }
> > 
> > ?
> 
> It's close, but no. That would cause a crash with a stacktrace only showing
> CallWithEHFrame. By telling the ABI to stop searching for an exception
handler,
> it effectively re-winds the stack back up and calls std::terminate from the
> place where |throw| was originally called. If you want the gory details, see
the
> linked bug.

Hey, crazy-talker here, I wonder if there's a way to unit test _that_?  Like
maybe a death test that HiybbprqagFunction() is indeed on the crash stack?  We
probably don't have such a test in the current code, of course...

[Nico, 2015-07-09 20:27:48]

On 2015/07/09 20:16:43, Robert Sesek wrote:
> On 2015/07/09 19:36:22, Nico wrote:
> > there are no dumb questions there are no dumb questions there are no dumb
> > questions
> 
> :) this is all quite subtle
> 
>
https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
> File base/mac/call_with_eh_frame_asm.S (right):
> 
>
https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
> base/mac/call_with_eh_frame_asm.S:15: .cfi_startproc
> On 2015/07/09 19:36:22, Nico wrote:
> > After starting at this for a bit, isn't this morally identical to
> > 
> >   CallWithEHFrame(void (^block)()) {
> >     @try {
> >       block();
> >     } @catch (id type) {
> >       CHECK(false);
> >     }
> >   }
> > 
> > ?
> 
> It's close, but no. That would cause a crash with a stacktrace only showing
> CallWithEHFrame. By telling the ABI to stop searching for an exception
handler,
> it effectively re-winds the stack back up and calls std::terminate from the
> place where |throw| was originally called. If you want the gory details, see
the
> linked bug.

I tried! The bug said something about rethrows and this doesn't have a rethrow.
But you're right, the rethrow is irrelevant – this is about fooling phase 1 of
unwinding, not doing something during phase 2. I'll look at this some more then.

[Nico, 2015-07-09 20:43:11]

base lgtm as far as I can tell

(the stack alignment comment below is because clang writes a .align line there)

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
File base/mac/call_with_eh_frame_asm.S (right):

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:14: 
do you need any stack alignment here?

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:40: // Landing pad for the exception handler.
This should never be called, since
As it's never called, maybe just an ud2 is enough? Don't care too much though.

[Robert Sesek, 2015-07-10 16:56:09]

On 2015/07/09 20:21:40, Scott Hess (OOO 7.10-7.19) wrote:
> Hey, crazy-talker here, I wonder if there's a way to unit test _that_?  Like
> maybe a death test that HiybbprqagFunction() is indeed on the crash stack?  We
> probably don't have such a test in the current code, of course...

I spent some time looking at this, but it seems tricky given the number of build
configs and ways we run tests. In some build configs, we don't symbolize stacks,
and so we'd have to rely on testing the function pointer addresses, which would
then require some sort of communication between the death test and its inferior
to to get that address. But then in some test runners, stack traces don't even
get printed, so that's not really workable.

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
File base/mac/call_with_eh_frame_asm.S (right):

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:14: 
On 2015/07/09 20:43:11, Nico wrote:
> do you need any stack alignment here?

Yeah, 16-byte alignment. Done.

https://codereview.chromium.org/1212093002/diff/140001/base/mac/call_with_eh_...
base/mac/call_with_eh_frame_asm.S:40: // Landing pad for the exception handler.
This should never be called, since
On 2015/07/09 20:43:11, Nico wrote:
> As it's never called, maybe just an ud2 is enough? Don't care too much though.

ud2 would definitely "be enough", but the ABI is pretty explicit about calling
the catch function, and it's harmless to do so.

[Robert Sesek, 2015-07-10 17:42:24]

The CQ bit was checked by rsesek@chromium.org

[Robert Sesek, 2015-07-10 17:42:25]

The patchset sent to the CQ was uploaded after l-g-t-m from shess@chromium.org,
thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1212093002/#ps160001
(title: "Align stack")

[commit-bot: I haz the power, 2015-07-10 17:44:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1212093002/160001

[commit-bot: I haz the power, 2015-07-10 19:16:35]

Committed patchset #4 (id:160001)

[commit-bot: I haz the power, 2015-07-10 19:17:37]

Patchset 4 (id:??) landed as
https://crrev.com/73dc3d5a6345ddd43a1a54f06dd4058be8a9842b
Cr-Commit-Position: refs/heads/master@{#338332}

[Reid Kleckner, 2015-07-10 19:42:35]

rnk@chromium.org changed reviewers:
+ rnk@chromium.org

[Reid Kleckner, 2015-07-10 19:42:36]

I guess this is kind of like WrappedWindowProc for Mac.

Can't you just call through a noexcept function? C++ says that when a function
unwinds through a noexcept frame, it calls std::terminate. My understanding is
that on platforms using Itanium EH (posix), this happens before cleanups run, so
you should get the whole stack frame.

It might be worth a shot, and would save you from implementing the custom EH
personality.

I have vague memories that the iOS linker doesn't like it when you have more
than one EH personality in your binary.

[Robert Sesek, 2015-07-10 19:43:50]

On 2015/07/10 19:42:36, Reid Kleckner wrote:
> I guess this is kind of like WrappedWindowProc for Mac.
> 
> Can't you just call through a noexcept function? C++ says that when a function
> unwinds through a noexcept frame, it calls std::terminate. My understanding is
> that on platforms using Itanium EH (posix), this happens before cleanups run,
so
> you should get the whole stack frame.
> 
> It might be worth a shot, and would save you from implementing the custom EH
> personality.
> 
> I have vague memories that the iOS linker doesn't like it when you have more
> than one EH personality in your binary.

Yeah I tried noexcept too, but it basically behaves like a rethrow from the
function marked noexcept. See
https://code.google.com/p/chromium/issues/detail?id=503128#c6.

[Reid Kleckner, 2015-07-10 19:53:55]

On 2015/07/10 19:43:50, Robert Sesek wrote:
> Yeah I tried noexcept too, but it basically behaves like a rethrow from the
> function marked noexcept. See
> https://code.google.com/p/chromium/issues/detail?id=503128#c6.

Hm, that's just Clang being dumb. This example gives a good stack trace when
compiled with GCC on Linux:

void g() {
  throw 32;
}
void f() noexcept {
  g();
}
int main() {
  f();
}

You could probably skip the personality function if you used the LSDA table that
GCC produces with __gxx_personality_v0.

[Nico, 2015-07-10 19:58:47]

On Fri, Jul 10, 2015 at 12:53 PM, <rnk@chromium.org> wrote:

> On 2015/07/10 19:43:50, Robert Sesek wrote:
>
>> Yeah I tried noexcept too, but it basically behaves like a rethrow from
>> the
>> function marked noexcept. See
>> https://code.google.com/p/chromium/issues/detail?id=503128#c6.
>>
>
> Hm, that's just Clang being dumb. This example gives a good stack trace
> when
> compiled with GCC on Linux:
>

Even with -fno-exceptions?


>
> void g() {
>   throw 32;
> }
> void f() noexcept {
>   g();
> }
> int main() {
>   f();
> }
>
> You could probably skip the personality function if you used the LSDA
> table that
> GCC produces with __gxx_personality_v0.
>
> https://codereview.chromium.org/1212093002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2015-07-10 22:59:30]

On Fri, Jul 10, 2015 at 12:58 PM, Nico Weber <thakis@chromium.org> wrote:

> On Fri, Jul 10, 2015 at 12:53 PM, <rnk@chromium.org> wrote:
>
>> On 2015/07/10 19:43:50, Robert Sesek wrote:
>>
>>> Yeah I tried noexcept too, but it basically behaves like a rethrow from
>>> the
>>> function marked noexcept. See
>>> https://code.google.com/p/chromium/issues/detail?id=503128#c6.
>>>
>>
>> Hm, that's just Clang being dumb. This example gives a good stack trace
>> when
>> compiled with GCC on Linux:
>>
>
> Even with -fno-exceptions?
>

For which part of the program? I was testing with exceptions enabled for
the whole thing.

In Chromium, you'd need to arrange for the noexcept() function to have EH
enabled, and to build it with GCC. Given that GCC isn't available on Mac,
so you're probably better off just checking in an assembly file like
Robert's with an LSDA that looks like the one GCC emits. At this point,
there's not much advantage over what you've got. It just saves you from
defining your own personality. =/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.