[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #55 from Iain Sandoe <iains at gcc dot gnu.org> ---
this is actually a duplicate of 44107 - it is the unwinder failing that causes
java codes (including ejc1) to hang/fail.

*** This bug has been marked as a duplicate of bug 44107 ***

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #56 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
Bug 41991 depends on bug 44107, which changed state.

Bug 44107 Summary: gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
Bug 41991 depends on bug 44107, which changed state.

Bug 44107 Summary: gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
         Resolution|WONTFIX                     |---

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
Bug 41991 depends on bug 44107, which changed state.

Bug 44107 Summary: gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #54 from howarth at nitro dot med dot uc dot edu  2010-08-23 16:32 -------
http://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/Process/Utility/libunwind/src/UnwindLevel1-gcc-ext.c

contains the sources for the libunwind in darwin10 (which shows the aborting
and non-functional unwinder calls.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #53 from howarth at nitro dot med dot uc dot edu  2010-08-22 04:56 -------
gcc/unwind-dw2-fde-darwin.c only uses

          __deregister_frame_info_bases (image->fde);

out of the non-functional unwinder calls for SL's libunwind.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #52 from howarth at nitro dot med dot uc dot edu  2010-08-21 02:24 -------
Also the additional clarification that...

> The UnwindLevel1-gcc-ext.c source file in lldb is the same as in SnowLeopard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #51 from howarth at nitro dot med dot uc dot edu  2010-08-21 00:55 -------
An additional clarification from the darwin unwinder developers on the status
of the libunwind sources from Snow Leopard...

> Everything down in the darwin layer is supposed to be open source.  It was
> a glitch that our libunwind did not get the right sign offs to make that
> happen in SnowLeopard.
>
> A fork was made in libunwind and incorporated into the open source lldb  
> project.  You can view those sources at:
> 
> http://llvm.org/svn/llvmproject/lldb/trunk/source/Plugins/Process/Utility/libunwind/src/UnwindLevel1-gcc-ext.c
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #50 from howarth at nitro dot med dot uc dot edu  2010-08-21 00:31 -------
According to the darwin unwinder maintainers in the Snow Leopard libunwind
sources...

// The following functions are implemented to just call abort
_Unwind_GetDataRelBase
_Unwind_GetTextRelBase
_Unwind_FindEnclosingFunction

//  The following functions are empty and do nothing
__register_frame_info_bases
__register_frame_info
__register_frame_info_table_bases
__register_frame_info_table
__register_frame_table
__deregister_frame_info
__deregister_frame_info_bases


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[iains at gcc dot gnu dot org]

------- Comment #49 from iains at gcc dot gnu dot org  2010-08-17 13:13 -------
the patch attached to 

http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01249.html

solves the problem by suppression of the epilogues in _eh_frames;
 the patch might be an incomplete solution to darwin<->dwarf2 issues.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #48 from howarth at nitro dot med dot uc dot edu  2010-08-11 15:23 -------
These messages from the Apple developers also are useful in explaining the
situation...

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #47 from howarth at nitro dot med dot uc dot edu  2010-08-11 13:42 -------
Also from a the darwin unwinder maintainer...

> I  took a look at the bug report you made.   Right off, I can tell that  
> the problem is that _Unwind_FindEnclosingFunction() is not  
> implemented.  Well, it is implemented as a not_implemented macro...   
> It is an FSF extension and has some semantics that can't be supported.
...
> _Unwind_Find_FDE is implemented on 10.6.
> 
> The general issue is that on 10.6 and later the dwarf unwind info may  
> not exist.  It may be replaced (by the linker tool) with compact  
> unwind info.  So any function that assumes FDEs exist may not work.

This is the reason that the  _Unwind_FindEnclosingFunction() call is
re-exported
under a different name in libgcc_ext. This call requires _Unwind_Find_FDE and
has been replaced with a not_implemented macro which silently aborts. A radar
is open to have the gross use of not_implemented macros replaced with a check
if -no-compact-unwind is in use. In that case, the compatibility unwinder in
libSystem (which supports FDEs) would be in use and those calls could be made
functional again.
    Note that this all stems from the fact that darwin10 has the compact unwind
code generation as the default. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #46 from howarth at nitro dot med dot uc dot edu  2010-08-11 13:14 -------
(In reply to comment #44)
> I do not think the current solution is complete/correct.

Don't confuse the darwin9 and darwin10 unwinder issues. They are 
different incompatiibilities with the darwin unwinder. Also keep in mind
that darwin9 uses an unwinder derived from libgcc whereas darwin10
uses a compatibility unwinder from libSystem.


> Taking the case of Darwin9/OSX 10.5:
> 
> (a) the code for _Unwind_FindEnclosingFunction &c. as posted on
> http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc
> (AFAICT from browsing it online) --  so I'm not sure why we added in the
> darwin10_Unwind_FindEnclosingFunction (it's the same code as already present in
> the system lib).   [having said that, even if the system code _is_ broken and
> unusable, (b) applies. and one needs to work around the breakage without
> bypassing said system code] 
> 

Read http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html which explains
the logic of re-exporting _Unwind_FindEnclosingFunction() under a different
name for
darwin10.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[andreast at gcc dot gnu dot org]

------- Comment #45 from andreast at gcc dot gnu dot org  2010-08-11 12:50 -------
I no longer have time to work on this.


-- 

andreast at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|andreast at gcc dot gnu dot |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[iains at gcc dot gnu dot org]

------- Comment #44 from iains at gcc dot gnu dot org  2010-08-11 12:32 -------
I do not think the current solution is complete/correct.

For 4.5.x and current trunk we still have a significant problem.  (4.4.x 
apparently still works, as of 4.4.5/r163091, at least for trivial cases)

[apollo is i686-darwin9 with r163091 bootstrapped and installed;
CWD=build-top-level].

apollo:gcc-4-5-branch-build$ /GCC/gcc-4-5-install/bin/gcj-4.5
../tests/HelloWorld.java --main=HelloWorld -o hw
gcj-4.5: Internal error: Abort trap (program ecj1):
FAILS

apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc
/GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o
hw
.................................................^^^^^^^^^^^^^^^^^^^^
OK - builds...

try to invoke the generated exe:
apollo:gcc-4-5-branch-build./hw
... a long wait ...   (on powerpc-darwin9 .. you get some interesting error
messages about repeated allocation of 1Gb memory chunks :/).
Abort trap

apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc ./hw
Hello, World

Incidentally, this applies equally if one starts from  HelloWorld.class

It seems to me that we have some dependancy issue that is causing libgcj to
link (some) symbols from <fsf>/libgcc_s.1dylib that should really be linked
from /usr/lib/libgcc_s.1.dylib - i.e. the unwinder is being invoked in two
different libs :(  see ****

=========

4.6-trunk behaves the same on Darwin9,   I've not tried Darwin10 (for reasons
which should be evident below).

=========

Taking the case of Darwin9/OSX 10.5:

(a) the code for _Unwind_FindEnclosingFunction &c. as posted on
http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc
(AFAICT from browsing it online) --  so I'm not sure why we added in the
darwin10_Unwind_FindEnclosingFunction (it's the same code as already present in
the system lib).   [having said that, even if the system code _is_ broken and
unusable, (b) applies. and one needs to work around the breakage without
bypassing said system code] 

(b) As the design(s) stand, we can only have one unwinder..
the choices are:

 1/ to use the system one in which case you can integrate your code with
system-supplied libraries [which is what, I suspect, the majority of users
want]

 2/ You can replace the system unwinder with the one in
<fsf-path>/libgcc_s.1.dylib - in which case you must point DYLD to that before
invoking any code generated by gcj (including the compiler itself).  That code
cannot use _any_ system facilities that might require the unwinder.
(ergo, the test-suite passes, but one can't build a general application using
arbitrary system facilities).

it seems we have (2) at present, and I wonder how useful that is to the
majority of end users?

(I guess there is also option (3) -> overwrite the system libgcc_s with the
<fsf> one .. but, if you do that, then you must take responsibility for any
other system breakage or security issues you cause ... not a route I'd
recommend for most end-users ;)).

=========

**** Incidentally, this is the whole reason we implemented the libgcc_ext.dylib
--- so that extensions to gcc (like emutls) could be applied to OSX without
interfering with the unwinder ;)  

.. and that is the reason that both /usr/lib/libgccs.1.dylib  _and_
<fsf>/libgcc_s.1.dylib are linked into darwin executables, (taking advantage of
the different namespaces).

However, in this case,  if  I regress the darwin10_Unwind_FindEnclosingFunction
change out, the code still fails - which indicates to me that:

(i)  somewhere else in the build of libgcj or the classpath there is a
dependency on some part of the unwinder that is being satisfied by a link from
<fsf>/libgcc_s.1dylib  (although a look at the Makefile didn't show anything
obvious, perhaps someone more familiar with libjava would be able to spot it?). 

(ii) or..  that there's a bug/incompatibility between the system unwinder & fsf
gcc that we haven't worked around.

in the case of (ii) the endgame is much the same as for darwin 10 .... 

=========

For Darwin10/OSX10.6

(a) I'm not sure that the current libjava design applies; it seems that the
relevant routines might have been replaced by no-ops (from comments posted
elsewhere, and a quick check of otool -tv -p _Unwind_FindEnclosingFunction).  
I.E the unwinder has changed to a different implementation.. 

However, as for darwin9,  (b) applies - one can "replace" the system unwinder
with the one in libgcc - but, again, that means the user will be limited to
self-contained code.

=====

If no-one has time to implement an integration of libjava with the Darwin 10
unwinders [and/or fix the breakage with Darwin9] (I don't, sorry), then
essentially gcj > 4.5 is unusable on current Darwin in any other manner than
stand-alone (and, frankly, I wonder how generally useful that is?).


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu dot org,
                   |                            |iains at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[gcc at ryandesign dot com]

------- Comment #43 from gcc at ryandesign dot com  2010-06-20 06:57 -------
Is there a reason the 3 fixes Andreas committed in February were not backported
to the 4.4 branch? I just ran into "Internal error: Abort trap (program ecj1)"
with 4.4.4 on Snow Leopard 10.6.4 and applying those patches fixed it.


-- 

gcc at ryandesign dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc at ryandesign dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

------- Comment #42 from howarth at nitro dot med dot uc dot edu  2010-02-03 03:33 -------
Fixed on *-apple-darwin10. The gcj failures on intel darwin9 are due to a
different unwinder bug. Leaving open for darwin9.


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i686/x86_64-apple-darwin*   |i686/x86_64-apple-darwin9
   GCC host triplet|i686/x86_64-apple-darwin*   |i686/x86_64-apple-darwin9
 GCC target triplet|i686/x86_64-apple-darwin*   |i686/x86_64-apple-darwin9
            Summary|gcj segfaults on i686-apple-|gcj segfaults on i686-apple-
                   |darwin* and x86_64-apple-   |darwin9 and x86_64-apple-
                   |darwin*                     |darwin9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991