This bug doesn't appear to be present in current gcc trunk on x86_64-apple-darwin10.

I also have 32 bit gcc 4.4.1 on a MacBook Pro (Snow Leopard 10.6.2 as well) obtained outside of darwinports:

>gcc -v
Using built-in specs.
Target: i386-apple-darwin9.7.0
Configured with: ./configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.1 20090623 (prerelease) (GCC)

and it experiences a similar problem (but only when compiled with -m64):

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x00007fff85225fe6 __kill + 10
1   libSystem.B.dylib             	0x00007fff852c6e32 abort + 83
2   libgcc_s.1.dylib              	0x0000000100183c92 uw_init_context_1 + 146
3   libgcc_s.1.dylib              	0x00000001001842ce _Unwind_RaiseException + 62
4   libstdc++.6.dylib             	0x0000000100073db9 __cxa_throw + 89
5   crash                         	0x0000000100000bfb dummy() + 201
6   crash                         	0x0000000100000c84 main + 52
7   crash                         	0x0000000100000b10 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00007fff5fbff3b0  rcx: 0x00007fff5fbfef58  rdx: 0x0000000000000000
  rdi: 0x0000000000005896  rsi: 0x0000000000000006  rbp: 0x00007fff5fbfef70  rsp: 0x00007fff5fbfef58
   r8: 0x00000001002fc0a0   r9: 0x00000001002fc0a4  r10: 0x00007fff85222026  r11: 0x0000000000000206
  r12: 0x00007fff5fbff4f0  r13: 0x0000000100073db9  r14: 0x00007fff5fbfef80  r15: 0x0000000000000000
  rip: 0x00007fff85225fe6  rfl: 0x0000000000000206  cr2: 0x0000000100186b0e

Binary Images:
       0x100000000 -        0x100000ff7 +crash ??? (???) <87DD3854-E919-9E63-A7E1-D459EBDB7B82> /Users/vlad/CONTENT/PRJ/crash/crash
       0x100003000 -        0x1000a4fef +libstdc++.6.dylib ??? (???) <791E4340-8218-E2DD-CEBD-5A343975BA5E> /usr/local/lib/x86_64/libstdc++.6.dylib
       0x100176000 -        0x100189ff1 +libgcc_s.1.dylib ??? (???) <CCB54A5C-47D8-820A-59E3-55965BF5E635> /usr/local/lib/libgcc_s.1.dylib
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld
    0x7fff806fe000 -     0x7fff80702ff7  libmathCommon.A.dylib ??? (???) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff851d7000 -     0x7fff85395ff7  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib

Model: MacBookPro2,2, BootROM MBP22.00A5.B07, 2 processors, Intel Core 2 Duo, 2.33 GHz, 4 GB, SMC 1.12f5

(In reply to comment #1)
> This bug doesn't appear to be present in current gcc trunk on
> x86_64-apple-darwin10.
> 

Jack, how should I interpret your comment? That all is well in 4.4.3 branch or something? Or that you cannot reproduce it on your end in 4.4.2?

If one wanted to leverage darwinports how would one get a 4.4.x version of gcc that does not have this issue? It seems like a basic failure of exception hanlding mechanism.

Same results here for fink gcc 4.4.2 (both 32 and 64 bit) and gcc 4.3.3 (only 64 bit) on Snow Leopard 10.6.2 MacBook Pro. 

Same results on a custom Sep 2009 build of gcc 4.5 on Snow Leopard (64 bit mode).

(In reply to comment #3)
> (In reply to comment #1)
> > This bug doesn't appear to be present in current gcc trunk on
> > x86_64-apple-darwin10.
> > 
> 
> Jack, how should I interpret your comment? That all is well in 4.4.3 branch or
> something? Or that you cannot reproduce it on your end in 4.4.2?
> 

I would suspect this may mean that the bug can go latent at times. Current gcc trunk
means gcc 4.5.

(In reply to comment #4)
> Same results here for fink gcc 4.4.2 (both 32 and 64 bit) and gcc 4.3.3 (only
> 64 bit) on Snow Leopard 10.6.2 MacBook Pro. 
> 

I would avoid gcc 4.3.x on darwin10 as none of the darwin10 fixes were backported.

I am somewhat unsure about what our best course of action is at this point. Can we discuss this in gnu forums? Could I help by providing diagnostics?

I'd like to use 4.4.x for its OpenMP support etc in preference to the xcode version. I see that many (all?) prerequisites for building gcc are available through fink: gmp, ppl, fmpr, etc. I wonder if I could leverage fink to get all of the dependencies and then try building the current against those.

Jack, since you're the maintainer of the fink package you probably build it all the time. Would be able to point in the right direction with the above idea, assuming a vanilla fink install in /sw? I feel lost among the many svn branches already...

Well, I think my scheme worked: I have succeeded in reverse engineering the 4.4.2 fink scripts into something I could use to build 4.5 trunk against the prerequisite libs installed via fink.

Indeed, 4.5 trunk does not appear to have this issue:

[10:00:53] TEMP>g++-4.5 -v -save-temps test.cpp -o crash
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../src/configure --prefix=/sw/lib/gcc4.5.trunk --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 20091128 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/cc1plus -E -quiet -v -D__DYNAMIC__ test.cpp -fPIC -mmacosx-version-min=10.6.2 -mtune=generic -fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../x86_64-apple-darwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0
 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0/x86_64-apple-darwin10
 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0/backward
 /sw/lib/gcc4.5.trunk/include
 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/include
 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/cc1plus -fpreprocessed test.ii -fPIC -quiet -dumpbase test.cpp -mmacosx-version-min=10.6.2 -mtune=generic -auxbase test -version -o test.s
GNU C++ (GCC) version 4.5.0 20091128 (experimental) (x86_64-apple-darwin10)
	compiled by GNU C version 4.5.0 20091128 (experimental), GMP version 4.3.1, MPFR version 2.4.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.5.0 20091128 (experimental) (x86_64-apple-darwin10)
	compiled by GNU C version 4.5.0 20091128 (experimental), GMP version 4.3.1, MPFR version 2.4.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f85e2aae35d4b378debe824f8e82886d
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 as -arch x86_64 -force_cpusubtype_ALL -o test.o test.s
COMPILER_PATH=/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/
LIBRARY_PATH=/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o crash -lcrt1.10.5.o -L/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0 -L/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../.. test.o -lstdc++ -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'

[10:01:04] TEMP>./crash
CAUGHT

So, using 4.5 trunk works around this issue... But ouch: 4.5 is almost 2x slower than 4.4...

Slower in runtime or in compile-time?

(In reply to comment #11)
> Slower in runtime or in compile-time?
> 

Compile-time.

(In reply to comment #12)
> Compile-time.

configure with --enable-checking=release to turn off checks that are enabled by default in pre-release builds, that will give a better comparison between the 4.4.2 release and 4.5 snapshot

(In reply to comment #13)
> (In reply to comment #12)
> > Compile-time.
> 
> configure with --enable-checking=release to turn off checks that are enabled by
> default in pre-release builds, that will give a better comparison between the
> 4.4.2 release and 4.5 snapshot
> 

Thank you for a useful tip. I have re-built the same snapshot:

Using built-in specs.
COLLECT_GCC=gcc-4.5
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../src/configure --enable-checking=release --prefix=/sw/lib/gcc4.5.trunk --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 20091128 (experimental) (GCC) 

It did make a noticeable difference. With 4.4.2 and 4.5 snapshot installed in parallel dirs, I ran the same build in two shells and simply pointing the builder from one version to another. The times are quite reproducible:

4.4.2: ~ 337 sec
4.5:   ~ 466 sec

(averages of two runs each). So, 4.5 snapshot is 40% slower at compile time. This is quite a bit better than without --enable-checking=release (which was close to 2x slower) but seems a tad heavy price to pay to just have exceptions working ...

This bug affects Ada as well.
It happens with gcc-4_4-branch HEAD as of 31 Dec 2009, and with earlier releases too (specifically, 4.3.4+AdaCore modifications; this compiler is AdaCore's Leopard release with one added RTS function to replace sigreturn()).

Confirmed on gcc version 4.5.1 20100506 (prerelease).

(In reply to comment #16)
> Confirmed on gcc version 4.5.1 20100506 (prerelease).
Confirmed fixed or confirmed present?

The Ada version of this test executes correctly for 4.5.0:

$ gnatgcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.5.0-x86_64/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0-x86_64/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5.0/configure --prefix=/opt/gcc-4.5.0-x86_64 --disable-multilib --enable-languages=c,ada --with-gmp=/opt/gnu --with-mpfr=/opt/gnu --with-mpc=/opt/gnu --build=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 (GCC) 

$ cat raiser.adb 
with Ada.Text_IO; use Ada.Text_IO;
procedure Raiser is
begin
   begin
      raise Constraint_Error;
   exception
      when Constraint_Error =>
         Put_Line ("CE raised.");
   end;
end Raiser;

$ ./raiser 
CE raised.

I can confirm the bug on my system (MacOS 10.6.3, Intel Core i7) with g++ 4.4.2, 4.4.3 and 4.4.4. 

However, I have discovered a workaround.  Linking with -lpthread makes the problem go away, both for this simple test case, and my larger program where I too discovered the bug.  My program only started failing when I turned off the OpenMP stuff.  However, if I leave OpenMP off, but link with -lpthread anyway, the exception stuff works fine.  Likewise, this example program works correctly when I compile with -lpthread.

*** Bug 44954 has been marked as a duplicate of this bug. ***

*** Bug 43277 has been marked as a duplicate of this bug. ***

*** Bug 43493 has been marked as a duplicate of this bug. ***

I wonder if some of the dups are actually caused by not building gcc with --enable-fully-dynamic-string which is needed on Snow Leopard, but wasn't done by macports until recently: https://trac.macports.org/ticket/22234

I suppose this is all "user" errors which might be avoided by some more
target-os specific specs magic.

Is this PR still present?

The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2.  I no longer have access to a 10.6 machine, so I cannot confirm whether it is fixed with 4.8 on that system.

(In reply to Dominique d'Humieres from comment #24)
> Is this PR still present?

Not with g++ (or Ada) in 4.9.0 on Max OS X 10.9.2 (darwin13.1.0).

> The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2. 
> I no longer have access to a 10.6 machine, so I cannot confirm whether
> it is fixed with 4.8 on that system.

For the test in comment 0, I get CAUGHT on x86_64-apple-darwin10 down to 4.5.4 (with 4.4.7 the test aborts) and on  powerpc-apple-darwin9 down to 4.4.7 (fink builds).

So I am closing this PR as FIXED.

I'd like to reopen this issue as we are still seeing this with as new gcc as 4.8.4 (we've been unable to build anything newer). Unfortunately I do not seem to have the access rights to reopen the bug. Help?

We've primarily been using 4.6.4 but we also did a test build with 4.8.4 to see if a newer gcc solved the issue. Unfortunately the problem is the same, with the same stack trace.

We have however found that the problem seems to be an incompatibility between OS X's unwinder and gcc's (something we found various other gcc bugs and mailing lists discussions on).

Or normal way of doing things is to statically link libstdc++ and libgcc_eh. This results in crashing programs. If we inject libSystem before libgcc_eh however, we get the system unwind routines and the program works fine. This is not quite the same as the previous cases mentioned on this bug, but the dumps show that a custom libgcc_s is being used so it should be equivalent.

Not sure what the proper fix is but our plan is to bastardise gcc a bit and remove the unwinding routines to make sure the system ones are always used.

> I'd like to reopen this issue as we are still seeing this with as new gcc
> as 4.8.4 (we've been unable to build anything newer). Unfortunately I do
> not seem to have the access rights to reopen the bug. Help?

I can reopen the PR, but I don't see the point:
(1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc version 4.4.7
(I get 'CAUGHT' for all the other revisions I have tested on powerpc-apple-darwin9, x86_64-apple-darwin10, and x86_64-apple-darwin14.
(2) You should be able to build 4.9 and 5.0 without any patch for x86_64-apple-darwin* and a few for powerpc-apple-darwin9 and 5.0.
(3) Why are you not using a more recent version of OS X?

(In reply to Dominique d'Humieres from comment #29)
> I can reopen the PR, but I don't see the point:
> (1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc
> version 4.4.7
> (I get 'CAUGHT' for all the other revisions I have tested on
> powerpc-apple-darwin9, x86_64-apple-darwin10, and x86_64-apple-darwin14.

I'm not sure what we're doing differently in that case. Are you sure you are using libgcc_s from your gcc and not getting the routines from libSystem? What if you statically link libstdc++ and libgcc_eh like we do?

> (2) You should be able to build 4.9 and 5.0 without any patch for
> x86_64-apple-darwin* and a few for powerpc-apple-darwin9 and 5.0.

Sorry, my bad. It was other issues preventing us from moving our development platform to 4.9. We should be able to do a test build. Do you think anything has changed since 4.8.4 though?

> (3) Why are you not using a more recent version of OS X?

We need to produce binaries that most people can run, and 10.6 seemed like a good cut-off for now. We did however see the same crashes running the binary on 10.10. We have not tested using a newer target for the gcc build though.

(In reply to Pierre Ossman from comment #28)
> Or normal way of doing things is to statically link libstdc++ and libgcc_eh.
> This results in crashing programs. If we inject libSystem before libgcc_eh
> however, we get the system unwind routines and the program works fine. This
> is not quite the same as the previous cases mentioned on this bug, but the
> dumps show that a custom libgcc_s is being used so it should be equivalent.
> 

You might check out the original posting on this issue...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

IMHO, the static linkage of -lgcc_eh is evil as it potentially breaks the requirement that only a single unwinder (always the system one) be used.

(In reply to Jack Howarth from comment #31)
> 
> You might check out the original posting on this issue...
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html
> 

I believe that was one of the posts we found and what made us look at which unwind implementation was used.

> IMHO, the static linkage of -lgcc_eh is evil as it potentially breaks the
> requirement that only a single unwinder (always the system one) be used.

I can understand that. But in that case why keep the gcc unwinder on OS X? If it doesn't work then including it is just an accident waiting to happen. I would suggest something along the lines of the attached patch.

Created attachment 35198 [details]
Remove unwinder on OS X

(In reply to Pierre Ossman from comment #32)
> I can understand that. But in that case why keep the gcc unwinder on OS X?

Mainly inertia. The more important issue is weaning darwin off of the compatibility unwinder which is on borrowed time and may well disappear in the next OS release.

> If it doesn't work then including it is just an accident waiting to happen.
> I would suggest something along the lines of the attached patch.

We can reproduce this issue on OS X 10.12, please see below for a detailed analysis of the underlying problem.
This issue is fixed by the patch proposed by Pierre Ossman. Did this patch (or maybe a similar solution) make it upstream already?


Summary of cause:

The libgcc unwinder implementation is broken for all 64-bit builds of OS X (since 10.6) due to a non-backwards compatible change in the _keymgr API, which does not provide a process-wide image list anymore.


Details of cause:

This is the minimal example to reproduce the issue on OS X (>10.6):

  #include <iostream>
  int main() {
      try {
          throw 20;
      }
      catch (int e) {
          std::cout << "Exception No. " << e << "\n";
      }
      return 0;
  }

Running this application will cause a SIGABRT:

  g++ -static-libgcc -o failboat main.cpp  && ./failboat
  [1]    4047 abort      ./failboat

Stack trace of this failure is:

  ...
  #12 0x00007fff5fbff370 in ?? ()
  #13 0x00000001000987c1 in uw_init_context_1 ()
  #14 0x0000000100098e1e in _Unwind_RaiseException ()
  #15 0x000000010000d81b in __cxa_throw ()
  #16 0x0000000100000b30 in main () at main.cpp:4

We're failing an assert in uw_init_context_1 (gcc/libgcc/unwind-dw2.c:1578):

  code = uw_frame_state_for (context, &fs);
  gcc_assert (code == _URC_NO_REASON);

Specifically uw_frame_state_for returns code _URC_END_OF_STACK and this then fails the gcc_assert, which then  unwraps in a SIGABRT. uw_frame_state_for() calls _Unwind_Find_FDE() in gcc/libgcc/unwind-dw2.c:1249, which returns NULL however and the entire function therefore returns _URC_END_OF_STACK:

  fde = _Unwind_Find_FDE (context->ra + _Unwind_IsSignalFrame (context) - 1, &context->bases);
  if (fde == NULL)
    {
      return _URC_END_OF_STACK;
    }

_Unwind_Find_FDE() is defined in gcc/libgcc/unwind-dw2-fde.c:1027, EXCEPT on OS X (aka. Darwin), where it is reimplemented in gcc/libgcc/config/unwind-dw2-fde-darwin.c:244!

This implementation uses the _keymgr API to access Dwarf2 object lists and ELF images (with the KEYMGR_GCC3_DW2_OBJ_LIST and KEYMGR_GCC3_LIVE_IMAGE_LIST keys, respectively).
The function first checks the Dwarf2 object lists, then falls back to using the original implementation (which has been renamed to _Unwind_Find_registered_FDE()) before searching the ELF images in examine_objects:

  the_obj_info =
    _keymgr_get_and_lock_processwide_ptr (KEYMGR_GCC3_DW2_OBJ_LIST);
  if (! the_obj_info)
    the_obj_info = calloc (1, sizeof (*the_obj_info));

  if (the_obj_info != NULL)
    {
      /* code removed for brevity */
      ret = _Unwind_Find_registered_FDE (pc, bases);
    }

  /* OK, didn't find it in the list of FDEs we've seen before,
     so go through and look at the new ones.  */
  if (ret == NULL)
    ret = examine_objects (pc, bases, the_obj_info == NULL);

Here the first call to KEYMGR_GCC3_DW2_OBJ_LIST returns NULL, thus an empty object list is allocated. _Unwind_Find_registered_FDE() returns NULL too, since it operates only on previously seen objects, of which there are none yet. Finally, examine_objects is finally called, which contains:

  image = _keymgr_get_and_lock_processwide_ptr (KEYMGR_GCC3_LIVE_IMAGE_LIST);

Note how the KEYMGR_GCC3_DW2_OBJ_LIST list is used as a "cache" of previously seen Dwarf2 objects and is first populated by examine_objects() using the KEYMGR_GCC3_LIVE_IMAGE_LIST.

However, on 64-bit builds of OS X, KEYMGR_GCC3_LIVE_IMAGE_LIST always returns NULL and so the image information can never be retrieved. The reason for this is found in the implementation of keymgr.c, which is published here: https://opensource.apple.com/source/keymgr/keymgr-28/keymgr.c.auto.html.

At the very bottom, in __keymgr_initializer() it says:

  #if __x86_64__
    /* On Mac OS X 10.6, libunwind in libSystem.dylib implements all unwinding functionality. */
    /* libunwind does not use keymgr, so there is no need to maintain KEYMGR_GCC3_LIVE_IMAGE_LIST */
    /* in sync with dyld's list of images.  But there might be some i386 or ppc applications that */
    /* carry around there own copy of the unwinder (from libgcc.a) and need KEYMGR_GCC3_LIVE_IMAGE_LIST. */
  #else
    /* register with dyld so that we are notified about all loaded mach-o images */
    _dyld_register_func_for_add_image (dwarf2_unwind_dyld_add_image_hook);
    _dyld_register_func_for_remove_image (dwarf2_unwind_dyld_remove_image_hook);
  #endif /* __x86_64__ */

On 64-bit builds of OS X these images are simply never added. The libgcc unwinder code can therefore never work, since it relies on this information.

(In reply to Niklas Hauser from comment #35)
> We can reproduce this issue on OS X 10.12, please see below for a detailed
> analysis of the underlying problem.

The underlying issue is understood and we've worked around it to for the case of "-static-libgcc" [PR80556].

Please could you identify:
 1. the version of GCC you're testing? (the ones mentioned in the PR here are well out of 'support').  Although there are probably work-around patches that could be applied

 2. the command line(s)

I have some patches in progress to tidy up the CRT/libgcc/unwinder stuff (which do, essentially, remove the unwinder from the build for later darwin - but leave them in place for Darwin9 etc.)

(In reply to Iain Sandoe from comment #36)
> The underlying issue is understood and we've worked around it to for the
> case of "-static-libgcc" [PR80556].

Oh, we worked on this at the same time.
The bug is gone for us on gcc trunk with your changes, thanks!
 
> Please could you identify:
>  1. the version of GCC you're testing? (the ones mentioned in the PR here
> are well out of 'support').  Although there are probably work-around patches
> that could be applied

I was working with gcc trunk from early Sept. which didn't have your patch yet.

>  2. the command line(s)

Simply ./configure --disable-bootstrap --enable-languages=c,c++ plus the usual directory/path flags.
Example is compiled with g++ -static-libgcc .

> I have some patches in progress to tidy up the CRT/libgcc/unwinder stuff
> (which do, essentially, remove the unwinder from the build for later darwin
> - but leave them in place for Darwin9 etc.)

Yes, I was going to suggest removing the unwinder code for 64b builds too, didn't work on any patches though.

Did you apply your patch to trunk only? I didn't find it in the GCC 7 branch.
Would you consider back porting it?

(In reply to Niklas Hauser from comment #37)
> (In reply to Iain Sandoe from comment #36)


> Did you apply your patch to trunk only? I didn't find it in the GCC 7 branch.
> Would you consider back porting it?

OK - let's move any more discussion to 80556 - and I would prefer to back-port a "real" fix rather than the work-around (although, JFTR, the current work-around works for me on 5.4.1, 6.4, 7.2 and trunk).