Bug 174612 - Crash on first startup
Crash on first startup
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Tom Tromey
:
: 176410 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-30 13:08 EST by Robin Green
Modified: 2014-08-11 01:46 EDT (History)
5 users (show)

See Also:
Fixed In Version: gcc-4.1.0-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-23 13:48:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 13212 None None None Never

  None (edit)
Description Robin Green 2005-11-30 13:08:35 EST
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):
eclipse-platform-3.1.1-1jpp_1fc.FC4.4

How reproducible:
Always

Steps to Reproduce:
1. rm -rf $HOME/.eclipse $HOME/workspace
2. eclipse -vmargs -Dosgi.locking=none
  
Actual results:
Just before the main window is about to appear, a dialog box appears saying the
VM exited with code 1.

Expected results:
No crash

Additional info:
libgcj-4.0.2-8.fc4
Comment 1 Robin Green 2005-11-30 13:23:42 EST
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.
Comment 2 Andrew Overholt 2005-12-02 15:55:17 EST
So shall we leave this open?  x86_64 is the leading cause of bugs for us ;)
Comment 3 Robin Green 2005-12-03 07:12:18 EST
Well, I suggested a workaround. Maybe you could patch eclipse not to use Mozilla
for the Welcome panel on x86_64, for now?
Comment 4 josip 2005-12-09 05:05:53 EST
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).
Comment 5 Andrew Overholt 2005-12-22 19:44:56 EST
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?
Comment 6 Andrew Overholt 2005-12-22 19:45:27 EST
*** Bug 176410 has been marked as a duplicate of this bug. ***
Comment 7 Gilboa Davara 2005-12-22 20:11:13 EST
Renaming /etc/gre.d/gre64.conf to /etc/gre.d/gre64.conf.old
Works for me.

Thanks.
Comment 8 Robin Green 2005-12-23 05:42:33 EST
(In reply to comment #5)
> Is this okay with everyone for now?

Fine by me
Comment 9 Anthony Green 2006-01-03 15:02:04 EST
(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.
Comment 10 Andrew Overholt 2006-01-03 15:09:23 EST
(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?
Comment 11 Anthony Green 2006-01-03 15:20:47 EST
(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.

Comment 12 Anthony Green 2006-01-03 16:10:04 EST
I proposed a solution here:

https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00002.html
Comment 13 Andrew Overholt 2006-01-05 16:09:32 EST
I have verified that this is fixed in java-1.4.2-gcj-compat-1.4.2.0-40jpp_59rh.
 Thanks, Anthony and others.
Comment 14 Justin Conover 2006-01-22 12:23:51 EST
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 ~
Comment 15 Anthony Green 2006-01-27 10:21:34 EST
The LD_PRELOAD hack was reverted, so this bug is back.  I'm reopening this
bugzilla entry.
Comment 16 Stephen John Smoogen 2006-01-27 13:27:09 EST
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.
Comment 17 Igor Foox 2006-01-27 13:36:35 EST
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.
Comment 18 Tom Tromey 2006-02-03 21:34:40 EST
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.
Comment 19 Robin Green 2006-03-23 13:48:53 EST
Fixed in FC5.

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

Note You need to log in before you can comment on or make changes to this bug.