Bug 2885

Summary: Frysk cannot be started when linked against libunwind libraries
Product: frysk Reporter: Rick Moseley <rmoseley>
Component: generalAssignee: Rick Moseley <rmoseley>
Severity: normal    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 1839, 3076    

Description Rick Moseley 2006-07-06 18:57:11 UTC
If frysk includes the libunwind.a library when it is linked, it cannot be
activated.  It aborts during startup.  Using gdb to monitor frysk during startup
yields the following info:

gdb ./frysk/gui/FryskGui GNU gdb Red Hat Linux ( Copyright 2004
Free Software Foundation, Inc. GDB is free software, covered by the GNU General
Public License, and you are welcome to change it and/or distribute copies of it
under certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was
configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run Starting program:
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb68000
[Thread debugging using libthread_db enabled]
[New Thread -1208415664 (LWP 27611)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208415664 (LWP 27611)]
0x066b9c06 in __gcj_personality_v0 () from /usr/lib/libgcj.so.7
(gdb) bt
#0  0x066b9c06 in __gcj_personality_v0 () from /usr/lib/libgcj.so.7
#1  0x083af627 in _Unwind_Resume (exception_object=0x43fa0)
at ../../../../frysk/frysk-imports/libunwind/src/unwind/unwind-internal.h:118
#2  0x068ffb4c in java::lang::ClassLoader::loadClass () from /usr/lib/libgcj.so.7
#3  0x068ffaf4 in java::lang::ClassLoader::loadClass () from /usr/lib/libgcj.so.7
#4  0x068e8e5f in java::lang::ClassLoader::loadClass () from /usr/lib/libgcj.so.7
#5  0x06996a4d in java::util::ResourceBundle::tryBundle () from /usr/lib/libgcj.so.7
#6  0x06996df9 in java::util::ResourceBundle::tryBundle () from /usr/lib/libgcj.so.7
#7  0x0699c885 in java::util::ResourceBundle::getBundle () from /usr/lib/libgcj.so.7
#8  0x0699d15e in java::util::Calendar::getBundle () from /usr/lib/libgcj.so.7
#9  0x069a0d39 in java::util::Calendar::Calendar () from /usr/lib/libgcj.so.7
#10 0x069a0df6 in java::util::GregorianCalendar::GregorianCalendar () from
#11 0x069a1a7a in java::util::GregorianCalendar::GregorianCalendar () from
#12 0x069a1adc in java::util::GregorianCalendar::GregorianCalendar () from
#13 0x06967242 in java::text::SimpleDateFormat::SimpleDateFormat () from
#14 0x06765576 in gnu::java::net::protocol::jar::Connection::__U3c_clinit__U3e_
() from /usr/lib/libgcj.so.7
#15 0x066e381c in java::lang::Class::initializeClass () from /usr/lib/libgcj.so.7
#16 0x066ac1b6 in _Jv_AllocObjectNoFinalizer () from /usr/lib/libgcj.so.7
#17 0x06765eb4 in gnu::java::net::protocol::jar::Handler::openConnection () from
#18 0x06917d76 in java::net::URL::openConnection () from /usr/lib/libgcj.so.7
#19 0x06929154 in
java::net::URLClassLoader$JarURLLoader::URLClassLoader$JarURLLoader () from
#20 0x06929613 in java::net::URLClassLoader::addURLImpl () from /usr/lib/libgcj.so.7
#21 0x06929abd in java::net::URLClassLoader::addURL () from /usr/lib/libgcj.so.7
#22 0x0670edbc in
gnu::gcj::runtime::HelperClassLoader::addDirectoriesFromProperty () from
#23 0x0670ef22 in gnu::gcj::runtime::BootClassLoader::BootClassLoader () from
#24 0x066eafe6 in java::lang::VMClassLoader::initBootLoader () from
#25 0x069037e0 in java::lang::VMClassLoader::initialize () from /usr/lib/libgcj.so.7
#26 0x066acb3f in _Jv_CreateJavaVM () from /usr/lib/libgcj.so.7
#27 0x066ad7f3 in _Jv_RunMain () from /usr/lib/libgcj.so.7
#28 0x066ad9a4 in _Jv_RunMain () from /usr/lib/libgcj.so.7
#29 0x066ad9eb in JvRunMain () from /usr/lib/libgcj.so.7
#30 0x080da131 in main (argc=-1074108216, argv=0x8619500) at /tmp/ccXNslU7.i:14

It appears that libgcj is not handling something inside of one of the header
files of libunwind.  Andrew Haley is reviewing this info now.
Comment 1 Rick Moseley 2006-07-11 14:59:57 UTC
Thanks to Andrew Haley who found out what the problem was we have been able to
resolve.  Here is Andrew's e-mail on the problem:

The problem is that you have linked frysk in such a way that it uses
part of libunwindand part of libgcc for exception handling .  So,
symbol resolution in FryskGui goes like this:

     4411:     binding file /lib/libc.so.6 [0] to /lib/libgcc_s.so.1 [0]: normal
symbol `_Unwind_Find_FDE' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /usr/lib/libgcj.so.7
[0]: normal symbol `_ZN14_Jv_StackTrace13UnwindTraceFnEP15_Unwind_ContextPv'
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_Backtrace' [GCC_3.3]
     4411:     binding file /lib/libgcc_s.so.1 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_Find_FDE' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetRegionStart' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetIP' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_RaiseException' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetLanguageSpecificData' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetIPInfo' [GCC_4.2.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_SetGR' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_SetIP' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to
./frysk-gui/frysk/gui/FryskGui [0]: normal symbol `_Unwind_Resume' [GCC_3.0]

Note that all of libgcj's exception handling is linked to
libgcc_s.so.1 except for `_Unwind_Resume', which is linked to the
libunwind version of that symbol that is built into FryskGui.  As far
as I can see this can never work, because the context structure used
in `_Unwind_RaiseException' and `_Unwind_Resume' must be the same, and
they must be satisfied from the same library.

FryskGui exports just _one_ libunwind function, and as soon as it gets
called the program crashes.
-bash-3.1$ nm ./frysk-gui/frysk/gui/FryskGui | grep _Unwind_
083af4e0 T __libunwind_Unwind_Resume
083af4e0 T _Unwind_Resume

So, the way to fix frysk is to make sure that libgcc_s.so is in the
link path before libunwind.  This causes the libunwind version of
_Unwind_Resume not to be put into FryskGui.

I linked FryskGui like this:

-Dgnu.gcj.runtime.NameFinder.demangle=false \
-Dgnu.gcj.runtime.NameFinder.use_addr2line=false \
-lgcc_s \
frysk/gui/FryskGui.o \
libfrysk-gui.a \
../frysk-gtk/libfrysk-gtk.a ...

This problem is really due to mixing dynamic and static libraries.  I
imagine -- but I haven't tried -- that if you used a dynamically
linked version of libunwind it would be OK.


P.S.  gcj on trunk doesn't call `_Unwind_Resume' at all; this is a 4.1 issue.

I resolved the problem for now by forcing the gcc library to be searched for
symbol resolution before libunwind by putting an "-lgcc_s" before the
libunwind.a in the link statement.  This lets us statically link libunwind.a.
Comment 2 Andrew Cagney 2006-07-11 15:14:33 UTC
Rick, where exactly is the offending symbol in libunwind (I've my doubts that
linking shared would fix it); and can it be renamed or removed locally?
Comment 3 Rick Moseley 2006-07-11 15:41:19 UTC
From what I can tell from the conversations with Andrew Haley the offending
symbol is "_Unwind_Resume".  This symbol seems to be used by both libgcj and

I did try to link shared by replacing the libunwind.a with
-L../frysk-imports/libunwind/src and that did indeed fix the problem.  So, when
libunwind is linked in statically, that symbol gets resolved out of that library
at runtime and the shared stuff gets searched later it seems.  Linking in
libunwind shared, the symbol gets plucked out of the libgcj library first and
all is well.

I thought that we would prefer most libraries be linked statically, so I chose
to add the "-lgcc_s" line in the link before the libunwind.a lib so the symbol
would be resolved from the libgcj library and we could still link libunwind in