JDK-6515362 : fix for 6374419 suppresses real error message from the linker
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2007-01-19
  • Updated: 2012-10-08
  • Resolved: 2007-08-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7 Other
5.0u14,hs10Fixed 6u2 b01Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-2136684 - Misleading error message if 32bit dll used together with 64 bit VM
Relates :  
JDK-6374419 - Misleading error message if 32bit dll used together with 64 bit VM
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/
25-01-2007