United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6515362 fix for 6374419 suppresses real error message from the linker
6515362 : fix for 6374419 suppresses real error message from the linker

Details
Type:
Bug
Submit Date:
2007-01-19
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2007-08-24
Component:
hotspot
OS:
solaris_9
Sub-Component:
runtime
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6u2

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
While reading forums I've tripped across several users who are rightly confused UnsatisfiedLinkErrors of the form:

Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: Can't load IA 32-bit .so on a IA 32-bit platform

instead of the infinitely more helpful:

Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: undefined symbol: adminGIDField

The code added to fix 6374419 suppresses the real error message from the linker in this case.  That could should probably only trigger if the library and the platform are different.  Given that we went to the trouble to backport this to an 1.5 update release this should also be fixed in a 1.5 update release.

Here are two cases where users on our forums were confused by this message

http://forum.java.sun.com/thread.jspa?threadID=792436
http://forum.java.sun.com/thread.jspa?threadID=5126164

                                    

Comments
EVALUATION

Introduced in 5.0 u10 b01 and 6.0 b80

There are several problems in the code

1) libraries with EM_SPARC and EM_SPARC32PLUS in e_machine field of .so header are compatible. In fact Sun Studio on v9 machine generates by default EM_SPARC32PLUS library and gcc generates EM_SPARC libraries for 32-bit targets. This was causing the redicules output message:  Can't load Sparc 32-bit .so on a Sparc 32-bit platform. 
Same token: there is a potential problem with EM_386 and EM_486.

2) There may me many reasons why dlopen failed. The old code only checks if file exists, may be opened and if e_machine field matches current architecture and then assumes that architecture is not right. This overlooks any other reasons why library could not be opened. The code should compare if the architecture is right fo this library and if it is - report what dlerror() reported.

3) Code should evaluate little endian/big endian field of .so head. Otherwise examining elf_head may not be done correctly (byte order).

4) In version 6.0 and 7.0

bool failed_to_read_elf_head= (sizeof(elf_head)==
(os::read(file_descriptor, &elf_head,sizeof(elf_head)))) ;

should be 

bool failed_to_read_elf_head=(sizeof(elf_head)!= 
(::read(file_descriptor, &elf_head,sizeof(elf_head)))) ; 

Webrevs with the fix:
http://jruntime.east/~ik199011/my_webrevs/6515362_5.0_webrev/
http://jruntime.east/~ik199011/my_webrevs/6515362_6.0_webrev/
http://jruntime.east/~ik199011/my_webrevs/6515362_7.0_webrev/
                                     
2007-01-25



Hardware and Software, Engineered to Work Together