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

["howarth at nitro dot med dot uc dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #36 from howarth at nitro dot med dot uc dot edu  2009-12-17 23:30 -------
(In reply to comment #31)
> Interestingly gcc-4.4.2 with the proposed patch,
> http://gcc.gnu.org/ml/java/2009-12/msg00027.html, shows gcj crashing the same
> way as gcc trunk with the same patch....
> 
> (gdb) r testme.java
> -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.4/share/java/libgcj-4.4.2.jar
> -fsource=1.5 -ftarget=1.5 -fzip-dependency
> /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccyWYcT2.zip -fzip-target
> /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccHDO5f8.jar
> Starting program: /sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/ecj1
> testme.java
> -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.4/share/java/libgcj-4.4.2.jar
> -fsource=1.5 -ftarget=1.5 -fzip-dependency
> /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccyWYcT2.zip -fzip-target
> /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccHDO5f8.jar
> Reading symbols for shared libraries +++++. done
> 
> Program received signal SIGABRT, Aborted.
> 0x00007fff843d4fe6 in __kill ()
> (gdb) bt
> #0  0x00007fff843d4fe6 in __kill ()
> #1  0x00007fff84475e32 in abort ()
> #2  0x00007fff844bffc9 in _Unwind_FindEnclosingFunction ()
> #3  0x000000010000fcbc in gnu::classpath::VMStackWalker::getCallingClassLoader
> (pc=0x100980d1c) at
> ../../../gcc-4.4.2/libjava/gnu/classpath/natVMStackWalker.cc:104
> Previous frame inner to this frame (gdb could not unwind past this frame)
> 
> So the crash on darwin10 appears to be independent of the libgcc_ext changes
> added to gcc trunk.
> 

The Darwin unwinder maintainer had the following response to this backtrace....

    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.

   Do you know why it is being used?  It is just to tell if a code address is
   in static or dynamic (JIT) code?  Or darwin, you can call dladdr() find if
   a function is known to the dynamic loader.

So it would appear that since we now use the system libgcc in gcc trunk on
darwin,
the use of _Unwind_FindEnclosingFunction will have to be replaced with
something
more generic outside of libgcc.


-- 


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