[bugs #8611] classpath0.08: java.lang.Runtime.loadLibrary : causes UnsatisfiedLinkException when VM is intializing

[Mark Wielaard]

This mail is an automated notification from the bugs tracker
 of the project: classpath.

/**************************************************************************/
[bugs #8611] Latest Modifications:

Changes by: 
                Mark Wielaard <address@hidden>
'Date: 
                Fri 04/30/04 at 15:14 (Europe/Amsterdam)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
         Assigned to | None                      | mark
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Thanks. I made your suggestion a bit more abstract which cleaned up library 
loading a bit. Hopefully this prevents early bootstrap triggering of exception 
handling and it is hopefully be a little more efficient if your library path is 
large.

2004-04-30  Mark Wielaard  <address@hidden>
                                                                                
        Reported by Nikolay Fiykov [bugs #8611]
        * java/lang/Runtime.java (loadLib): New private method.
        (load): Call loadLib.
        (loadLibrary): Call loadLib.

diff -u -r1.6 Runtime.java
--- java/lang/Runtime.java      17 Apr 2004 17:08:22 -0000      1.6
+++ java/lang/Runtime.java      30 Apr 2004 15:08:12 -0000
@@ -670,11 +664,20 @@
    */
   public void load(String filename)
   {
+    if (loadLib(filename) == 0)
+      throw new UnsatisfiedLinkError("Could not load library " + filename);
+  }
+
+  // Private version of load(String) that doesn't throw Exception on
+  // load error, but it does do security checks (which can throw
+  // SecurityExceptions). Convenience method for early bootstrap
+  // process.
+  private int loadLib(String filename)
+  {
     SecurityManager sm = securityManager; // Be thread-safe!
     if (sm != null)
       sm.checkLink(filename);
-    if (VMRuntime.nativeLoad(filename) == 0)
-      throw new UnsatisfiedLinkError("Could not load library " + filename);
+    return VMRuntime.nativeLoad(filename);
   }
  
   /**
@@ -706,21 +709,18 @@
         filename = cl.findLibrary(libname);
         if (filename != null)
           {
-            load(filename);
-            return;
+           // Use loadLib so no UnsatisfiedLinkError are thrown.
+            if (loadLib(filename) != 0)
+             return;
           }
       }
+
     filename = System.mapLibraryName(libname);
     for (int i = 0; i < libpath.length; i++)
-      try
-        {
-          load(libpath[i] + filename);
-          return;
-        }
-      catch (UnsatisfiedLinkError e)
-        {
-          // Try next path element.
-        }
+      // Use loadLib so no UnsatisfiedLinkError are thrown.
+      if (loadLib(libpath[i] + filename) != 0)
+       return;
+
     throw new UnsatisfiedLinkError("Could not find library " + libname + ".");
   }
  







/**************************************************************************/
[bugs #8611] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8611>
Project: classpath
Submitted by: Nikolay Fiykov
On: Sun 04/18/04 at 15:00

Severity:  5 - Average
Resolution:  Fixed
Assigned to:  mark
Status:  Closed
Platform Version:  None


Summary:  classpath0.08: java.lang.Runtime.loadLibrary : causes 
UnsatisfiedLinkException when VM is intializing

Original Submission:  Hi,
While dealing with JAMVM I came across an exceptions related problem with 
java.lang.Runtime.loadLibrary.

Issue is that when scanning java.library.path dirs to find the required lib 
"loadLibrary" uses "load". In its turn "load" raise exeception if lib is not 
find.

In case of JAMVM when this exeception hapens during intialization it aborts VM. 
Because of that LD_LIBRARY_PATH is not scanned completely and lib is not 
located at all.

This also could be attributed to JAMVM specifics and probably it is true. Yet, 
I can understand also that VM exception handling may not be that "accurate" 
during VM build-up therefore I'd see it as Classpath issue as well.

Attached is a patch against Runtime.java which overcomes the problem by doing 
exactly what "load" does but without mentioned exception problem.

See sf.net/projects/jamvm:Forums-Help where this issues has been raised too.

-- niki

Follow-up Comments
------------------


-------------------------------------------------------
Date: Fri 04/30/04 at 15:14         By: mark
Thanks. I made your suggestion a bit more abstract which cleaned up library 
loading a bit. Hopefully this prevents early bootstrap triggering of exception 
handling and it is hopefully be a little more efficient if your library path is 
large.

2004-04-30  Mark Wielaard  <address@hidden>
                                                                                
        Reported by Nikolay Fiykov [bugs #8611]
        * java/lang/Runtime.java (loadLib): New private method.
        (load): Call loadLib.
        (loadLibrary): Call loadLib.

diff -u -r1.6 Runtime.java
--- java/lang/Runtime.java      17 Apr 2004 17:08:22 -0000      1.6
+++ java/lang/Runtime.java      30 Apr 2004 15:08:12 -0000
@@ -670,11 +664,20 @@
    */
   public void load(String filename)
   {
+    if (loadLib(filename) == 0)
+      throw new UnsatisfiedLinkError("Could not load library " + filename);
+  }
+
+  // Private version of load(String) that doesn't throw Exception on
+  // load error, but it does do security checks (which can throw
+  // SecurityExceptions). Convenience method for early bootstrap
+  // process.
+  private int loadLib(String filename)
+  {
     SecurityManager sm = securityManager; // Be thread-safe!
     if (sm != null)
       sm.checkLink(filename);
-    if (VMRuntime.nativeLoad(filename) == 0)
-      throw new UnsatisfiedLinkError("Could not load library " + filename);
+    return VMRuntime.nativeLoad(filename);
   }
  
   /**
@@ -706,21 +709,18 @@
         filename = cl.findLibrary(libname);
         if (filename != null)
           {
-            load(filename);
-            return;
+           // Use loadLib so no UnsatisfiedLinkError are thrown.
+            if (loadLib(filename) != 0)
+             return;
           }
       }
+
     filename = System.mapLibraryName(libname);
     for (int i = 0; i < libpath.length; i++)
-      try
-        {
-          load(libpath[i] + filename);
-          return;
-        }
-      catch (UnsatisfiedLinkError e)
-        {
-          // Try next path element.
-        }
+      // Use loadLib so no UnsatisfiedLinkError are thrown.
+      if (loadLib(libpath[i] + filename) != 0)
+       return;
+
     throw new UnsatisfiedLinkError("Could not find library " + libname + ".");
   }
  


-------------------------------------------------------
Date: Sun 04/18/04 at 22:07         By: None
THis is JamVM specific.  THe patch should be rejected, and JamVM fixed.






File Attachments
-------------------

-------------------------------------------------------
Date: Sun 04/18/04 at 15:00  Name: classpath-0.08-loadlibrary.patch  Size: 1KB  
 By: fikin

http://savannah.gnu.org/bugs/download.php?item_id=8611&amp;item_file_id=1201






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8611>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/