Bug 457849 - Eclipse crashes on startup
Summary: Eclipse crashes on startup
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 460239 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-04 22:53 UTC by Adam Huffman
Modified: 2018-04-11 10:05 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-02 12:55:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Screengrab of crash message on startup (59.90 KB, image/png)
2008-08-04 22:53 UTC, Adam Huffman
no flags Details

Description Adam Huffman 2008-08-04 22:53:50 UTC
Created attachment 313409 [details]
Screengrab of crash message on startup

Description of problem:
I have just installed the Fedora Eclipse group on a new F9 system upgraded to Rawhide.  Eclipse crashes on startup.

Version-Release number of selected component (if applicable):
eclipse-rcp-3.3.2-12.fc9.x86_64

How reproducible:
3 times

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Brennan Ashton 2008-08-05 07:32:32 UTC
Please post more information. How are you executing it could you post anything that is in the console if you run it from there
i.e. [user@localhost ~]$ eclipse

Comment 2 Andrew Overholt 2008-08-05 12:31:59 UTC
This is a known issue at the moment as we were holding off getting Eclipse 3.4 into rawhide until all of the Eclipse plugins were ready.  It's probably because the icu4j symlink is broken due to it upgrading for 3.4 but 3.3.2 being the only thing available.  We'll have 3.4 sometime this week.  Sorry about this.

Comment 3 Adam Huffman 2008-08-05 22:20:53 UTC
Actually, this might be a wider java problem?:

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

It may be that the yum upgrade to rawhide missed something.

Comment 4 Lillian Angel 2008-08-06 14:08:18 UTC
OpenJDK was updated in rawhide today. Can you try updating and reproducing this issue?

Comment 5 Adam Huffman 2008-08-09 10:36:08 UTC
Am running java-1.6.0-openjdk-1.6.0.0-0.20.b11.fc10.x86_64 and I still have the same problem.

Comment 6 Caolan McNamara 2008-08-11 09:01:20 UTC
wrt #3 given "java" reporting...

java: error while loading shared libraries: libjli.so: cannot open shared
object file: No such file or directory

I bet that using an explicit path of /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java works
as would $(readlink -f `which java`) to expand out the location of java explicitly ?

i.e. the problem is most likely that of expansion of $ORIGIN when there are links involved

readelf -d $(readlink -f `which java`) | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli]

and is related to the glibc ORIGIN changes that caused the more obvious and fixed bug 457560

If so, then this part at least is probably glibc's issue rather than openjdk's

Comment 7 Andrew Overholt 2008-08-11 12:31:37 UTC
Re-assigning component.

Comment 8 Lillian Angel 2008-08-11 14:09:46 UTC
I can't reproduce this on x86_64 with eclipse 3.3.2 or 3.4.

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)


Other similar reports suggest this is no longer a problem after they updated java-1.6.0-openjdk and java-1.6.0-openjdk-devel.

Do you have a crash report?

Comment 9 Caolan McNamara 2008-08-11 14:29:44 UTC
[caolan@Nom builds]$ rpm -q java-1.6.0-openjdk
java-1.6.0-openjdk-1.6.0.0-0.20.b11.fc10.x86_64
[caolan@Nom builds]$ rpm -q java-1.6.0-openjdk-devel
java-1.6.0-openjdk-devel-1.6.0.0-0.20.b11.fc10.x86_64
[caolan@Nom builds]$ java -version
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[caolan@Nom builds]$ which java
/usr/bin/java
[caolan@Nom builds]$ readlink -f `which java`
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java
[caolan@Nom builds]$ $(readlink -f `which java`) -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
[caolan@Nom builds]$ rpm -q glibc.x86_64
glibc-2.8.90-11.x86_64
[caolan@Nom builds]$

I still suspect that (this can't find libjli.so bit anyway) is some glibc ORIGIN following foo

Comment 10 Adam Huffman 2008-08-11 19:40:28 UTC
As per https://bugzilla.redhat.com/show_bug.cgi?id=457849#c6, invoking java does work when the full location is given.

I'm running the same versions listed in https://bugzilla.redhat.com/show_bug.cgi?id=457849#c9

Comment 11 Ulrich Drepper 2008-08-13 19:06:03 UTC
(In reply to comment #9)
> I still suspect that (this can't find libjli.so bit anyway) is some glibc
> ORIGIN following foo

I don't see anything wrong.  Look at the encoded path:

  $ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli

The binary is /usr/bin/java.  But none of

  /usr/lib/amd64

and

  /usr/jre

exists.

My guess is that previously the binary was in a different place (somewhere under /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64) and the path hasn't been adjusted.

Comment 12 Lillian Angel 2008-08-13 19:32:06 UTC
I double checked. None of the paths have changed. I can reproduce this problem on my own rawhide machine.

Comment 13 Caolan McNamara 2008-08-13 23:48:57 UTC
re #11

[caolan@Nom ~]$ which java
/usr/bin/java
[caolan@Nom ~]$ ls -asl /usr/bin/java
0 lrwxrwxrwx 1 root root 22 2008-01-29 14:49 /usr/bin/java -> /etc/alternatives/java
[caolan@Nom ~]$ ls -asl /etc/alternatives/java
0 lrwxrwxrwx 1 root root 46 2008-08-08 17:14 /etc/alternatives/java -> /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
[caolan@Nom ~]$ ls -asl /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
40 -rwxr-xr-x 1 root root 39584 2008-08-05 20:12 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
[caolan@Nom ~]$ readelf -d /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java|grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli]
[caolan@Nom ~]$ ls -asl /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/../lib/amd64/jli
total 28
 4 drwxr-xr-x 2 root root  4096 2008-08-09 04:20 .
 4 drwxr-xr-x 7 root root  4096 2008-08-08 17:14 ..
20 -rwxr-xr-x 1 root root 18216 2008-08-05 20:12 libjli.so
[caolan@Nom ~]$ strace java 2>&1| grep libjli
open("/lib64/tls/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libjli.so", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/lib64/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib64/libjli.so", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libjli.so", O_RDONLY)  = -1 ENOENT (No such file or directory)
writev(2, [{"java"..., 4}, {": "..., 2}, {"error while loading shared librar"..., 36}, {": "..., 2}, {"libjli.so"..., 9}, {": "..., 2}, {"cannot open shared object file"..., 30}, {": "..., 2}, {"No such file or directory"..., 25}, {"\n"..., 1}], 10java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Comment 14 Ulrich Drepper 2008-08-14 17:10:38 UTC
OK, this is a change in behavior.  And a bad one.  The kernel doesn't pass up a normalized path name and therefore we shouldn't use it at all.  I've reverted the code upstream.  Should be fixed with the next rawhide build of glibc.

Comment 15 Lillian Angel 2008-08-14 17:26:15 UTC
thank you!

Adam- does this fix your problem? Can we close the bug?

Comment 16 Lillian Angel 2008-08-27 14:12:15 UTC
*** Bug 460239 has been marked as a duplicate of this bug. ***

Comment 17 Michel Lind 2008-08-29 00:06:04 UTC
Ulrich, could you queue up the updated glibc on Koji? Adam and I cannot confirm that the change works, since there is no updated glibc to test against.

Comment 18 Matěj Cepl 2008-08-29 13:39:15 UTC
Yes, I can confirm that glibc-2.8.90-12.x86_64 works as it should. java -version gives reasonable answer.

Comment 19 Michel Lind 2008-08-29 15:45:25 UTC
Confirmed that it works here as well (x86_64)

Comment 20 Adam Huffman 2008-08-31 15:05:25 UTC
Yes, works for me now.


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