[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #38 from Iain Sandoe --- (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).
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #37 from Niklas Hauser --- (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?
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #36 from Iain Sandoe --- (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.)
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
Niklas Hauser changed:
What|Removed |Added
CC||niklas.hauser at arm dot com
--- Comment #35 from Niklas Hauser ---
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
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 0x7fff5fbff370 in ?? ()
#13 0x0001000987c1 in uw_init_context_1 ()
#14 0x000100098e1e in _Unwind_RaiseException ()
#15 0x0001d81b in __cxa_throw ()
#16 0x00010b30 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, );
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,
>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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #32 from Pierre Ossman ossman at cendio dot se --- (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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #33 from Pierre Ossman ossman at cendio dot se --- Created attachment 35198 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35198action=edit Remove unwinder on OS X
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #34 from Jack Howarth howarth.at.gcc at gmail dot com --- (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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #30 from Pierre Ossman ossman at cendio dot se --- (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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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?
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Jack Howarth howarth.at.gcc at gmail dot com changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #31 from Jack Howarth howarth.at.gcc at gmail dot com --- (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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Pierre Ossman ossman at cendio dot se changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #28 from Pierre Ossman ossman at cendio dot se --- 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.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR still present?
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #25 from Mike Jarvis michael at jarvis dot net --- 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.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #26 from simon at pushface dot org --- (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).
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #27 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.4/4.5/4.6] app SIGABRTs |unwinding issues on darwin |after a trivial nested | |throw/stack unwinding | Known to fail|| --- Comment #23 from Richard Guenther rguenth at gcc dot gnu.org 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.
