Red Hat Bugzilla – Bug 174612
Crash on first startup
Last modified: 2014-08-11 01:46:34 EDT
Description of problem:
Eclipse crashes on startup when used for the first time for a new user. If he
then runs it again, it crashes again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rm -rf $HOME/.eclipse $HOME/workspace
2. eclipse -vmargs -Dosgi.locking=none
Just before the main window is about to appear, a dialog box appears saying the
VM exited with code 1.
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
#3 0x00002aaaab80068d in java::lang::Thread::gen_name () at
#4 0x00002aaaab800bb0 in _Jv_AttachCurrentThread (name=0x0, group=0x0) at
#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 ()
#7 0x00002aaab3d9bbb7 in fn70_4 ()
#8 0x00002aaab99e2671 in NSGetModule () from
#9 0x00002aaab8ddbb66 in nsStreamCopierOB::FillOutputBuffer () from
#10 0x00002aaab8ddac35 in nsPipe::OnPipeException () from
#11 0x00002aaab8ddbe8d in nsStreamCopierOB::DoCopy () from
#12 0x00002aaab8ddbcd6 in nsAStreamCopier::Process () from
#13 0x00002aaab8ddc16f in nsAStreamCopier::HandleContinuationEvent () from
#14 0x00002aaab8df0b29 in PL_HandleEvent () from
#15 0x00002aaab99d9db8 in NSGetModule () from
#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
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.
(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:
I have verified that this is fixed in java-1.4.2-gcj-compat-220.127.116.11-40jpp_59rh.
Thanks, Anthony and others.
I have the same problem on x86_64 running rawhide
rpm -qa eclipse\*
rpm -qa java\*
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
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
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