This looks like our old friend, gcc bug 13212 !

#0  GC_local_malloc_atomic (bytes=48) at ../../../boehm-gc/pthread_support.c:324
#1  0x00002aaaab7c97b4 in _Jv_AllocString (len=8) at ./include/java-gc.h:57
#2  0x00002aaaab7ff0e4 in _Jv_NewString (chars=0x45a07e14, len=8) at
../../../libjava/java/lang/natString.cc:411
#3  0x00002aaaab80068d in java::lang::Thread::gen_name () at
../../../libjava/gcj/cni.h:48
#4  0x00002aaaab800bb0 in _Jv_AttachCurrentThread (name=0x0, group=0x0) at
../../../libjava/java/lang/natThread.cc:419
#5  0x00002aaaab7cbb02 in _Jv_JNI_AttachCurrentThread (name=0x0,
penv=0x45a07ee8, args=Variable "args" is not available.
) at ../../../libjava/jni.cc:2383
#6  0x00002aaab3dadb32 in callback ()
   from
/home/greenrd/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/42/1/.cp/libswt-gtk-3139.so
#7  0x00002aaab3d9bbb7 in fn70_4 ()
   from
/home/greenrd/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/42/1/.cp/libswt-gtk-3139.so
#8  0x00002aaab99e2671 in NSGetModule () from
/usr/lib64/mozilla-1.7.12/components/libnecko.so
#9  0x00002aaab8ddbb66 in nsStreamCopierOB::FillOutputBuffer () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#10 0x00002aaab8ddac35 in nsPipe::OnPipeException () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#11 0x00002aaab8ddbe8d in nsStreamCopierOB::DoCopy () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#12 0x00002aaab8ddbcd6 in nsAStreamCopier::Process () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#13 0x00002aaab8ddc16f in nsAStreamCopier::HandleContinuationEvent () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#14 0x00002aaab8df0b29 in PL_HandleEvent () from
/usr/lib64/mozilla-1.7.12/libxpcom.so
#15 0x00002aaab99d9db8 in NSGetModule () from
/usr/lib64/mozilla-1.7.12/components/libnecko.so
#16 0x00002aaab917d8f4 in PR_Select () from /usr/lib/../lib64/libnspr4.so
#17 0x00002aaaac6fe97c in start_thread () from /lib64/libpthread.so.0
#18 0x00002aaaac58a92e in clone () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()

The workaround - which works - is to disable mozilla support by renaming
/etc/gre.d/gre64.conf. But obviously you need a better solution for the RPM
build, one which doesn't affect other mozilla embedders.

So shall we leave this open?  x86_64 is the leading cause of bugs for us ;)

Well, I suggested a workaround. Maybe you could patch eclipse not to use Mozilla
for the Welcome panel on x86_64, for now?

The workaround (rename /etc/gre.d/gre64.conf on x86_64) works for me, too. 
Otherwise, eclipse crashes on startup (using
eclipse-platform-3.1.1-1jpp_1fc.FC4.4 and
java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.2).

I spoke with Anthony Green about this today.  He is going to push for a fix for
the gcc bug.  I don't really want to patch around this for now.

It does appear that the initial startup fails but subsequent startups work okay.
 If we get a fix, we can try to back-port it to FC4's gcc.  If that's not
possible, we can investigate patching around it.

Is this okay with everyone for now?

*** Bug 176410 has been marked as a duplicate of this bug. ***

Renaming /etc/gre.d/gre64.conf to /etc/gre.d/gre64.conf.old
Works for me.

Thanks.

(In reply to comment #5)
> Is this okay with everyone for now?

Fine by me

(In reply to comment #5)
> I spoke with Anthony Green about this today.  He is going to push for a fix for
> the gcc bug.  I don't really want to patch around this for now.

I had a look, and think that backporting a fix to libgcj would be hard.  I think
we should solve this by overriding pthread_create and the boehm pthread_create
wrapper in a .so we LD_PRELOAD prior to running Eclipse.

(In reply to comment #9)
> (In reply to comment #5)
> > I spoke with Anthony Green about this today.  He is going to push for a fix for
> > the gcc bug.  I don't really want to patch around this for now.
> 
> I had a look, and think that backporting a fix to libgcj would be hard.  I think
> we should solve this by overriding pthread_create and the boehm pthread_create
> wrapper in a .so we LD_PRELOAD prior to running Eclipse.

We no longer have a wrapper script.  How would we do this?

(In reply to comment #10)
> We no longer have a wrapper script.  How would we do this?

We could do this in the "java" wrapper program in java-gcj-compat.  It currently
just sets LD_LIBRARY_PATH.

I proposed a solution here:

https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00002.html

I have verified that this is fixed in java-1.4.2-gcj-compat-1.4.2.0-40jpp_59rh.
 Thanks, Anthony and others.

I have the same problem on x86_64 running rawhide

 rpm -qa eclipse\*
eclipse-platform-3.1.1-1jpp_15fc
eclipse-cdt-3.0.1-1jpp_3fc
eclipse-rcp-3.1.1-1jpp_15fc
eclipse-jdt-3.1.1-1jpp_15fc
eclipse-changelog-2.0.1_fc-23
eclipse-ecj-3.1.1-1jpp_15fc
eclipse-bugzilla-0.1.1_fc-6
eclipse-pydev-0.9.3_fc-13

rpm -qa java\*
java_cup-manual-0.10-0.k.1jpp_6fc
java-1.4.2-gcj-compat-1.4.2.0-40jpp_62rh
java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_62rh
java_cup-0.10-0.k.1jpp_6fc
java_cup-javadoc-0.10-0.k.1jpp_6fc
java-1.4.2-gcj-compat-src-1.4.2.0-40jpp_62rh


However, this does fix it for me:

 mv /etc/gre.d/gre64.conf ~

The LD_PRELOAD hack was reverted, so this bug is back.  I'm reopening this
bugzilla entry.

I am seeing a very similar problem on i386 FC4 standard. The box was a fresh
install with updates and states that it is unable to find/inititiate a Main
method in startup.jar. I need instructions on getting debugging info to you.

Stephen, you might be experiencing what's commented on in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177210 . Please take a look
at that.

I've got a patch for this bug in the works.
It has gone through a few revisions, I should get the
final one to Jakub early next week.

Fixed in FC5.

The relevant patch is here: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00181.html