[JIRA] [credentials] (JENKINS-20276) Native Library Error after upgrading ssh-agent from 1.3 to 1.4

Mon, 11 Aug 2014 06:58:08 -0700

Ok, I think I have the root cause.

The issue here is that Java, by default, can end up having the 32-bit library paths in the java.library.path system property and there is a bug in JNR's Platform.Linux:

@Override
        public String locateLibrary(final String libName, List<String> libraryPath) {
            FilenameFilter filter = new FilenameFilter() {
                Pattern p = Pattern.compile("lib" + libName + "\\.so\\.[0-9]+$");
                String exact = "lib" + libName + ".so";
                public boolean accept(File dir, String name) {
                    return p.matcher(name).matches() || exact.equals(name);
                }
            };

            List<File> matches = new LinkedList<File>();
            for (String path : libraryPath) {
                File[] files = new File(path).listFiles(filter);
                if (files != null && files.length > 0) {
                    matches.addAll(Arrays.asList(files));
                }
            }

            //
            // Search through the results and return the highest numbered version
            // i.e. libc.so.6 is preferred over libc.so.5
            //
            int version = 0;
            String bestMatch = null;
            for (File file : matches) {
                String path = file.getAbsolutePath();
                if (bestMatch == null && path.endsWith(".so")) {
                    bestMatch = path;
                    version = 0;
                } else {
                    String num = path.substring(path.lastIndexOf(".so.") + 4);
                    try {
                        if (Integer.parseInt(num) >= version) {
                            bestMatch = path;
                        }
                    } catch (NumberFormatException e) {
                    } // Just skip if not a number
                }
            }
            return bestMatch != null ? bestMatch : mapLibraryName(libName);
        }

The bug being that it will return the last match is all the matches have the same version (I suspect it is that (Integer.parseInt(num) >= version) should be (Integer.parseInt(num) > version) but I am not currently sure, as I have yet to dig into this fully)

So what you need to ensure is that the library paths (if they include a mix of 64bit and 32bit libraries) are a palindrome, now the search path is a combination of four system properties in order:

  • jnr.ffi.library.path
  • jaffl.library.path
  • jna.library.path
  • java.library.path

So what you want to do is see what the combined path for all of those is... and then (since you are here because there is a 32bit lib on that path) reverse the path and append it to java.library.path

A quicker fix is to just remove the 32-bit folders from java.library.path

By way of example, if I go to the System Information page for my CentOS 6.5 slave, I see that it says:

java.library.path /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

So I can either set the JVM options for that slave to include -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib:/lib:/lib64:/usr/lib64:/usr/java/packages/lib/amd64 (which is the palindrome trick) or I can simply remove the 32-bit directories from -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64

Either of these fixes the issue
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to