Bug 42159 - unwinding issues on darwin
Summary: unwinding issues on darwin
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.4.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 43277 43493 44954 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-24 00:59 UTC by Vlad
Modified: 2017-10-03 19:16 UTC (History)
12 users (show)

See Also:
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
Known to work:
Known to fail: 4.4.1, 4.4.2, 4.5.1
Last reconfirmed: 2010-05-18 10:28:59


Attachments
Remove unwinder on OS X (3.79 KB, patch)
2015-04-01 07:41 UTC, Pierre Ossman
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad 2009-11-24 00:59:50 UTC
A 64 bit build of gcc 4.4.2 installed via darwinports on a Mac Pro server running Snow Leopard 10.6.2 causes a crash in the following program:

>cat src/test.cpp 

#include <iostream>

struct X
{
        ~X () // crash disappears if there is no destructor
        {
        }
};

void
dummy ()
{
    X x;

    throw 0;
}

int main()
{
	try
	{
	    dummy ();
	}
	catch (...)
	{
	    std::cout << "CAUGHT" << std::endl;
	}

	return 0;
}

Instead of the expected "CAUGHT" the system pops up with:

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             	0x00007fff801a3fe6 __kill + 10
1   libSystem.B.dylib             	0x00007fff80244e32 abort + 83
2   libgcc_s.1.dylib              	0x00000001001a2aa2 uw_init_context_1 + 146
3   libgcc_s.1.dylib              	0x00000001001a2ef8 _Unwind_Resume + 72
4   crash                         	0x0000000100000cfe main + 0
5   crash                         	0x0000000100000d0a main + 12
6   crash                         	0x0000000100000c88 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00007fff5fbff560  rcx: 0x00007fff5fbff288  rdx: 0x0000000000000000
  rdi: 0x0000000000014c96  rsi: 0x0000000000000006  rbp: 0x00007fff5fbff2a0  rsp: 0x00007fff5fbff288
   r8: 0x00000001002fc0a0   r9: 0x00000001002fc0a4  r10: 0x00007fff801a0026  r11: 0x0000000000000206
  r12: 0x00007fff5fbff6a0  r13: 0x0000000100000cfe  r14: 0x00007fff5fbff2b0  r15: 0x0000000000000000
  rip: 0x00007fff801a3fe6  rfl: 0x0000000000000206  cr2: 0x00000001001a5924

Binary Images:
       0x100000000 -        0x100000ff7 +crash ??? (???) <1795FC81-D57C-8C65-42CB-984BCE974933> /Users/vlad/PRJ/test/crash
       0x100003000 -        0x1000a9fe7 +libstdc++.6.dylib ??? (???) <7ED4A235-4CEF-A737-9698-18B1301A9979> /sw/lib/gcc4.4/lib/libstdc++.6.dylib
       0x100195000 -        0x1001a8ff7 +libgcc_s.1.dylib ??? (???) <A31CA578-6BE8-891F-8F79-680CAAA8DE22> /sw/lib/gcc4.4/lib/libgcc_s.1.dylib
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld
    0x7fff80155000 -     0x7fff80313ff7  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib
    0x7fff8373b000 -     0x7fff8373fff7  libmathCommon.A.dylib ??? (???) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib

Model: MacPro4,1, BootROM MP41.0081.B04, 8 processors, Quad-Core Intel Xeon, 2.66 GHz, 16 GB, SMC 1.39f5

As long as a local object 'x' with a destructor is created prior to the 'throw' inside dummy(), the problem occurs.

[18:53:02] test>g++-4 -v -save-temps src/test.cpp -o crash
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --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.4.2 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 /sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/cc1plus -E -quiet -v -D__DYNAMIC__ src/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.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../x86_64-apple-darwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2
 /sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2/x86_64-apple-darwin10
 /sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2/backward
 /sw/lib/gcc4.4/include
 /sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/include
 /sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/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.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/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.4.2 (x86_64-apple-darwin10)
	compiled by GNU C version 4.4.2, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e5506cfd76732233066589d06543f3ba
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.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/:/sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/:/sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/:/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/:/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/
LIBRARY_PATH=/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/:/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'
 /sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/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.4/lib/gcc/x86_64-apple-darwin10/4.4.2 -L/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../.. test.o -lstdc++ -lgcc_s.10.5 -lgcc -lSystem
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic'

>./crash
Comment 1 Jack Howarth 2009-11-24 01:25:04 UTC
This bug doesn't appear to be present in current gcc trunk on x86_64-apple-darwin10.
Comment 2 Vlad 2009-11-24 01:37:09 UTC
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
Comment 3 Vlad 2009-11-24 15:48:58 UTC
(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.
Comment 4 aufpasser 2009-11-25 15:58:47 UTC
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. 
Comment 5 Vlad 2009-11-25 17:16:38 UTC
Same results on a custom Sep 2009 build of gcc 4.5 on Snow Leopard (64 bit mode).
Comment 6 Jack Howarth 2009-11-25 17:27:47 UTC
(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.
Comment 7 Jack Howarth 2009-11-25 17:29:02 UTC
(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.
Comment 8 Vlad 2009-11-28 06:42:33 UTC
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...
Comment 9 Vlad 2009-11-29 16:04:41 UTC
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
Comment 10 Vlad 2009-11-30 15:19:07 UTC
So, using 4.5 trunk works around this issue... But ouch: 4.5 is almost 2x slower than 4.4...
Comment 11 Richard Biener 2009-11-30 15:27:24 UTC
Slower in runtime or in compile-time?
Comment 12 Vlad 2009-11-30 16:07:12 UTC
(In reply to comment #11)
> Slower in runtime or in compile-time?
> 

Compile-time.



Comment 13 Jonathan Wakely 2009-11-30 16:46:52 UTC
(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



Comment 14 Vlad 2009-12-01 05:50:07 UTC
(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 ...
Comment 15 simon 2009-12-31 17:41:59 UTC
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()).
Comment 16 Francois-Xavier Coudert 2010-05-18 10:28:58 UTC
Confirmed on gcc version 4.5.1 20100506 (prerelease).
Comment 17 simon 2010-05-19 22:05:53 UTC
(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.
Comment 18 Mike Jarvis 2010-06-06 19:32:56 UTC
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.
Comment 19 Andrew Pinski 2010-07-15 16:57:56 UTC
*** Bug 44954 has been marked as a duplicate of this bug. ***
Comment 20 Andrew Pinski 2010-07-15 16:58:42 UTC
*** Bug 43277 has been marked as a duplicate of this bug. ***
Comment 21 Andrew Pinski 2010-07-15 16:58:48 UTC
*** Bug 43493 has been marked as a duplicate of this bug. ***
Comment 22 Jonathan Wakely 2010-07-15 17:03:35 UTC
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
Comment 23 Richard Biener 2010-09-30 10:37:10 UTC
I suppose this is all "user" errors which might be avoided by some more
target-os specific specs magic.
Comment 24 Dominique d'Humieres 2014-04-30 09:46:30 UTC
Is this PR still present?
Comment 25 Mike Jarvis 2014-04-30 12:42:30 UTC
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.
Comment 26 simon 2014-04-30 13:00:19 UTC
(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).
Comment 27 Dominique d'Humieres 2014-04-30 13:09:09 UTC
> 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.
Comment 28 Pierre Ossman 2015-03-31 14:20:25 UTC
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.
Comment 29 Dominique d'Humieres 2015-03-31 15:00:33 UTC
> 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?
Comment 30 Pierre Ossman 2015-03-31 15:17:00 UTC
(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.
Comment 31 Jack Howarth 2015-03-31 16:19:16 UTC
(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.
Comment 32 Pierre Ossman 2015-04-01 07:41:27 UTC
(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.
Comment 33 Pierre Ossman 2015-04-01 07:41:59 UTC
Created attachment 35198 [details]
Remove unwinder on OS X
Comment 34 Jack Howarth 2015-04-01 12:03:12 UTC
(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.
Comment 35 Niklas Hauser 2017-10-03 09:57:16 UTC
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.
Comment 36 Iain Sandoe 2017-10-03 10:11:01 UTC
(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.)
Comment 37 Niklas Hauser 2017-10-03 16:18:47 UTC
(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?
Comment 38 Iain Sandoe 2017-10-03 19:16:49 UTC
(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).