GCC Bugzilla Bug 28760

Compiled java programs that are linked statically with gcj segfault on startup
(starting with GCC 4.1.x):

  # gcj -g -static --main=test -Wl,--whole-archive -lnss_files_p -lnss_dns_p
-lresolv -lpthread -ldl -Wl,--no-whole-archive test.java
  # ./a.out
  Segmentation fault

with test.java being i.e.

    public class test {
     public static void main( String args[] ) {
       System.err.println( "Hello" ); }}

GDB tells me the program is crashing in:

  (gdb) bt
  #0  0x00000000 in ?? ()
  #1  0x081e89de in pthread_create (new_thread=0x86c733c, attr=0xbffffa04,
    start_routine=0x808fff0 <really_start>, arg=0x74ff8) at
../.././boehm-gc/pthread_support.c:1289
  #2  0x0808fee7 in _Jv_ThreadStart (thread=0x5cb18, data=0x86c7338,
    meth=0x808cd30 <_Jv_ThreadRun(java::lang::Thread*)>) at
../.././libjava/posix-threads.cc:488
  #3  0x0808c702 in java::lang::Thread::start (this=0x5cb18)
    at ../.././libjava/java/lang/natThread.cc:328
  #4  0x080620e4 in _Jv_CreateJavaVM (vm_args=0x0) at
../.././libjava/prims.cc:1334
  #5  0x080622da in _Jv_RunMain (vm_args=0x0, klass=0x8441fc0, name=0x0,
argc=1, argv=0xbffffd84,
    is_jar=false) at ../.././libjava/prims.cc:1355
  #6  0x08062468 in _Jv_RunMain (klass=0x8441fc0, name=0x0, argc=1,
argv=0xbffffd84, is_jar=false)
    at ../.././libjava/prims.cc:1401
  #7  0x0806249b in JvRunMain (klass=0x8441fc0, argc=1, argv=0xbffffd84)
    at ../.././libjava/prims.cc:1407
  #8  0x0804824c in main (argc=Cannot access memory at address 0x1
  ) at /tmp/ccYuSF5L.i:11

Obviously, in line 1289 of pthread_support.c GC_PTHREAD_REAL_NAME is null due
to  the fact that it is computed using dlvsym() in line 1218. Of course(?)
dlvsym() will return null if libpthread is statically linked.

My quick hack around the problem was to just disable the dlvsym() variation
(see attached patch). This seems to work for me.

Best regards,
Tom

Created an attachment (id=12087) [edit]
Ugly workaround GC_PTHREAD_CREATE_NAME segfault

Why are you trying to static link java code?  It will almost not work for other
cases.

(In reply to comment #2)
> Why are you trying to static link java code?  It will almost not work for other
> cases.
> 

We have 7.5X10^6 lines of code in about 800 classes that run fine statically
linked.  So it does in fact work.  As to why, the answer is startup time and
code size.

We probably should fix this at some point, but until we do, I guess either do
not statically link libc or use your work around.

A bug tracker is not the right place to discuss philosophy questions, so if
you'd like to continue the discussion, we should move over to e-mail or the gcj
mailing list (lookout for subject: "GCJ 4.1.1 and static linking - SEGV").
However, my answer to your (Andrew) question is: 

  - for portability: The binary I am building statically is supposed
    to work out-of-the-box on as many machines as ever possible
  - for stability: Some systems out there are known to have deficiencies,
    i.e. Debian/woody came with a not completely thread-safe glibc, so
    linking glibc statically solves these issues, too
  - for reproducibility: ask users that complain about issues in
    your software to try out the statically built version and if
    the problem stops you know you've found another combination of
    library versions your software does not work well with (or you
    can confirm that your software, not the runtime environment
    has a bug in the other case)

> It will almost not work for other cases.

I cannot confirm this. The project I'm trying to build statically with 4.1.1 is
built statically for years with earlier gcc versions with less problems than
the dynamic builds had ...

The "ugly workaround" (which works great for my static builds!) patches a
previous workaround:
http://gcc.gnu.org/ml/java-patches/2006-q1/msg00181.html
So this issue is related to #13212,which is assigned to Bryce:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
Maybe we want to note that 13212 blocks 28760, but in any event the longer term
solution for 28760 seems to be making sure that the non-workaround solution to
13212 works for static builds.

For a shorter-term solution, I wonder if a configure option could turn off
GC_PTHREAD_SYM_VERSION.

I think the PR 13212 fix probably fixed this on svn trunk.
Can one of you try that?

I checked out revision 117082 (trunk) and successfully built a few static
binaries with it.  So unless Thomas saw a different problem than I did, I'd say
it's fixed.

Configured with: ../gcc/configure --prefix=/var/local/gcc/tip_20060920
--mandir=/var/local/gcc/man --infodir=/var/local/gcc/info --enable-shared
--enable-threads=posix --disable-checking --host=i386-redhat-linux
--enable-java-awt=xlib --enable-libgcj --enable-languages=c,c++,java
--with-system-zlib --enable-__cxa_atexit
Thread model: posix

ok, I'm closing.
Please reopen if it is still a problem.