Problems calling FilePath.copyRecursiveTo() on a Mac
|
|
I've been banging my head on this all day, and it's time to ask for some
help. I'm adding a test case to JUnitResultArchiverTest to validate that some changes we're making don't break when the JUnit archiver is run on a slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a data set on the slave to archive from a test project. It works great on Linux, but fails on a Mac: Caused by: java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/-S/-SC42LvtEC4VMYuErMwfOE EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1020) at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) at com.sun.jna.Native.loadNativeLibrary(Native.java:678) at com.sun.jna.Native.<clinit>(Native.java:106) at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) at hudson.FilePath.readFromTar(FilePath.java:1724) at hudson.FilePath.access$300(FilePath.java:157) at hudson.FilePath$32.invoke(FilePath.java:1374) at hudson.FilePath$32.invoke(FilePath.java:1371) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) at hudson.remoting.UserRequest.perform(UserRequest.java:104) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:244) The spaces in the path are really + signs that got changed coming across the channel back to the master. If I catch the UnsatisfiedLinkError and print the path on the remote side, the + signs show up, so I think the remote side has the right path. If I skip the chmod call in readFromTar, the test succeeds, but that's obviously not the right solution. I tried to create a simple unit test to add to FilePathTest to test copyRecursiveTo directly, but annoyingly, that passes. So it seems that the extra slave process in the middle alters something. Anyone have any thoughts on what's going on? I've attached the two test methods. Thanks. -- Dean --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]  testCopyRecursiveTo.java (494 bytes) Download Attachment testSlaveArchive.java (1K) Download Attachment |
||||||||
|
Is this Intel Mac or PPC Mac? It looks like JNA doesn't have the proper binary for the platform in question. Dean Yu wrote: > I've been banging my head on this all day, and it's time to ask for some > help. I'm adding a test case to JUnitResultArchiverTest to validate that > some changes we're making don't break when the JUnit archiver is run on a > slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a > data set on the slave to archive from a test project. It works great on > Linux, but fails on a Mac: > > Caused by: java.lang.UnsatisfiedLinkError: Can't load library: > /var/folders/-S/-SC42LvtEC4VMYuErMwfOE > EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) > at java.lang.Runtime.load0(Runtime.java:770) > at java.lang.System.load(System.java:1020) > at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) > at com.sun.jna.Native.loadNativeLibrary(Native.java:678) > at com.sun.jna.Native.<clinit>(Native.java:106) > at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) > at hudson.FilePath.readFromTar(FilePath.java:1724) > at hudson.FilePath.access$300(FilePath.java:157) > at hudson.FilePath$32.invoke(FilePath.java:1374) > at hudson.FilePath$32.invoke(FilePath.java:1371) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) > at hudson.remoting.UserRequest.perform(UserRequest.java:104) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:244) > > The spaces in the path are really + signs that got changed coming across the > channel back to the master. If I catch the UnsatisfiedLinkError and print > the path on the remote side, the + signs show up, so I think the remote side > has the right path. > > If I skip the chmod call in readFromTar, the test succeeds, but that's > obviously not the right solution. I tried to create a simple unit test to > add to FilePathTest to test copyRecursiveTo directly, but annoyingly, that > passes. So it seems that the extra slave process in the middle alters > something. > > Anyone have any thoughts on what's going on? I've attached the two test > methods. Thanks. > > -- Dean > > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
||||||||
|
|
|
||||||||
|
|
Dean Yu wrote:
> Intel. OK, then there must be more to this than what I originally thought, because Intel Mac OS X is clearly supported. I'm curious why it comes up with weird path like this. Are we suspecting that somewhere in the remoting layer the path is messed up, causing System.load to be invoked with a wrong path name that doesn't exist? > > -- Dean > > > On 10/27/09 4:23 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: > >> >> Is this Intel Mac or PPC Mac? >> >> It looks like JNA doesn't have the proper binary for the platform in >> question. >> >> Dean Yu wrote: >>> I've been banging my head on this all day, and it's time to ask for some >>> help. I'm adding a test case to JUnitResultArchiverTest to validate that >>> some changes we're making don't break when the JUnit archiver is run on a >>> slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a >>> data set on the slave to archive from a test project. It works great on >>> Linux, but fails on a Mac: >>> >>> Caused by: java.lang.UnsatisfiedLinkError: Can't load library: >>> /var/folders/-S/-SC42LvtEC4VMYuErMwfOE >>> EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) >>> at java.lang.Runtime.load0(Runtime.java:770) >>> at java.lang.System.load(System.java:1020) >>> at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) >>> at com.sun.jna.Native.loadNativeLibrary(Native.java:678) >>> at com.sun.jna.Native.<clinit>(Native.java:106) >>> at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) >>> at hudson.FilePath.readFromTar(FilePath.java:1724) >>> at hudson.FilePath.access$300(FilePath.java:157) >>> at hudson.FilePath$32.invoke(FilePath.java:1374) >>> at hudson.FilePath$32.invoke(FilePath.java:1371) >>> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) >>> at hudson.remoting.UserRequest.perform(UserRequest.java:104) >>> at hudson.remoting.UserRequest.perform(UserRequest.java:48) >>> at hudson.remoting.Request$2.run(Request.java:244) >>> >>> The spaces in the path are really + signs that got changed coming across the >>> channel back to the master. If I catch the UnsatisfiedLinkError and print >>> the path on the remote side, the + signs show up, so I think the remote side >>> has the right path. >>> >>> If I skip the chmod call in readFromTar, the test succeeds, but that's >>> obviously not the right solution. I tried to create a simple unit test to >>> add to FilePathTest to test copyRecursiveTo directly, but annoyingly, that >>> passes. So it seems that the extra slave process in the middle alters >>> something. >>> >>> Anyone have any thoughts on what's going on? I've attached the two test >>> methods. Thanks. >>> >>> -- Dean >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
||||||||
|
|
|
||||||||
|
Are unicode characters involved? Remember that OSX has a normalising
file system... -Rob |
||||||||
|
|
|
||||||||
|
In reply to this post
by Dean Yu
|
||||||||
|
|
In reply to this post
by Dean Yu
Dean Yu wrote:
> I originally thought that was the problem. That something in the remoting > layer was decoding +'s into spaces. This may well be the case on the way > back from the slave when it reports the exception, but when I caught the > UnsatisfiedLinkError on the slave side and printed the path at that point, > it seemed correct: it had the plus signs in the path. So I don't think the > path is the issue. > > This problem is all the more annoying because OS X isn't letting me enter > that directory from a terminal window so I can poke around in it. I don't > know if that's related in any way. > > Do you have any other tips for debugging slaves created when the test > harness is running? Is there a way to set -Xdebug when the test harness > creates the slave process so I can attach a debugger to it? http://wiki.hudson-ci.org/display/HUDSON/Unit+Test > > -- Dean > > On 10/27/09 6:28 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: > >> Dean Yu wrote: >>> Intel. >> >> OK, then there must be more to this than what I originally thought, >> because Intel Mac OS X is clearly supported. >> >> I'm curious why it comes up with weird path like this. Are we suspecting >> that somewhere in the remoting layer the path is messed up, causing >> System.load to be invoked with a wrong path name that doesn't exist? >> >>> >>> -- Dean >>> >>> >>> On 10/27/09 4:23 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: >>> >>>> >>>> Is this Intel Mac or PPC Mac? >>>> >>>> It looks like JNA doesn't have the proper binary for the platform in >>>> question. >>>> >>>> Dean Yu wrote: >>>>> I've been banging my head on this all day, and it's time to ask for some >>>>> help. I'm adding a test case to JUnitResultArchiverTest to validate that >>>>> some changes we're making don't break when the JUnit archiver is run on a >>>>> slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a >>>>> data set on the slave to archive from a test project. It works great on >>>>> Linux, but fails on a Mac: >>>>> >>>>> Caused by: java.lang.UnsatisfiedLinkError: Can't load library: >>>>> /var/folders/-S/-SC42LvtEC4VMYuErMwfOE >>>>> EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) >>>>> at java.lang.Runtime.load0(Runtime.java:770) >>>>> at java.lang.System.load(System.java:1020) >>>>> at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) >>>>> at com.sun.jna.Native.loadNativeLibrary(Native.java:678) >>>>> at com.sun.jna.Native.<clinit>(Native.java:106) >>>>> at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) >>>>> at hudson.FilePath.readFromTar(FilePath.java:1724) >>>>> at hudson.FilePath.access$300(FilePath.java:157) >>>>> at hudson.FilePath$32.invoke(FilePath.java:1374) >>>>> at hudson.FilePath$32.invoke(FilePath.java:1371) >>>>> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) >>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:104) >>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:48) >>>>> at hudson.remoting.Request$2.run(Request.java:244) >>>>> >>>>> The spaces in the path are really + signs that got changed coming across >>>>> the >>>>> channel back to the master. If I catch the UnsatisfiedLinkError and print >>>>> the path on the remote side, the + signs show up, so I think the remote >>>>> side >>>>> has the right path. >>>>> >>>>> If I skip the chmod call in readFromTar, the test succeeds, but that's >>>>> obviously not the right solution. I tried to create a simple unit test to >>>>> add to FilePathTest to test copyRecursiveTo directly, but annoyingly, that >>>>> passes. So it seems that the extra slave process in the middle alters >>>>> something. >>>>> >>>>> Anyone have any thoughts on what's going on? I've attached the two test >>>>> methods. Thanks. >>>>> >>>>> -- Dean >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [hidden email] >>>>> For additional commands, e-mail: [hidden email] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
||||||||
|
|
In reply to this post
by Kohsuke Kawaguchi
|
||||||||
|
|
If you can tell me what url.getPath() was and what URLDecoder.decode(url.getPath()) is on this line, that would be very helpful. I believe the intention of this code is to get to the file that the URL is pointing to, and we need a bit more info to be able to suggest a fix to JNA. Dean Yu wrote: > I found the root of the problem. It's JNA, at > com.sun.jna.Native.loadNativeLibraryFromJar:705. It uses a URL to represent > the path to the shared library and calls URLDecoder.decode on it. I'm not > sure how this path is generated, but it's the value of java.io.tmpdir, which > is where the temporary shared library is copied into. It might be some MD5 > or something of my userID and I just got unlucky. > > -- Dean > > https://jna.dev.java.net/source/browse/jna/tags/3.2.2/jnalib/src/com/sun/jna > /Native.java?annotate=982 > > > On 10/27/09 6:28 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: > >> Dean Yu wrote: >>> Intel. >> >> OK, then there must be more to this than what I originally thought, >> because Intel Mac OS X is clearly supported. >> >> I'm curious why it comes up with weird path like this. Are we suspecting >> that somewhere in the remoting layer the path is messed up, causing >> System.load to be invoked with a wrong path name that doesn't exist? >> >>> >>> -- Dean >>> >>> >>> On 10/27/09 4:23 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: >>> >>>> >>>> Is this Intel Mac or PPC Mac? >>>> >>>> It looks like JNA doesn't have the proper binary for the platform in >>>> question. >>>> >>>> Dean Yu wrote: >>>>> I've been banging my head on this all day, and it's time to ask for some >>>>> help. I'm adding a test case to JUnitResultArchiverTest to validate that >>>>> some changes we're making don't break when the JUnit archiver is run on a >>>>> slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a >>>>> data set on the slave to archive from a test project. It works great on >>>>> Linux, but fails on a Mac: >>>>> >>>>> Caused by: java.lang.UnsatisfiedLinkError: Can't load library: >>>>> /var/folders/-S/-SC42LvtEC4VMYuErMwfOE >>>>> EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) >>>>> at java.lang.Runtime.load0(Runtime.java:770) >>>>> at java.lang.System.load(System.java:1020) >>>>> at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) >>>>> at com.sun.jna.Native.loadNativeLibrary(Native.java:678) >>>>> at com.sun.jna.Native.<clinit>(Native.java:106) >>>>> at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) >>>>> at hudson.FilePath.readFromTar(FilePath.java:1724) >>>>> at hudson.FilePath.access$300(FilePath.java:157) >>>>> at hudson.FilePath$32.invoke(FilePath.java:1374) >>>>> at hudson.FilePath$32.invoke(FilePath.java:1371) >>>>> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) >>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:104) >>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:48) >>>>> at hudson.remoting.Request$2.run(Request.java:244) >>>>> >>>>> The spaces in the path are really + signs that got changed coming across >>>>> the >>>>> channel back to the master. If I catch the UnsatisfiedLinkError and print >>>>> the path on the remote side, the + signs show up, so I think the remote >>>>> side >>>>> has the right path. >>>>> >>>>> If I skip the chmod call in readFromTar, the test succeeds, but that's >>>>> obviously not the right solution. I tried to create a simple unit test to >>>>> add to FilePathTest to test copyRecursiveTo directly, but annoyingly, that >>>>> passes. So it seems that the extra slave process in the middle alters >>>>> something. >>>>> >>>>> Anyone have any thoughts on what's going on? I've attached the two test >>>>> methods. Thanks. >>>>> >>>>> -- Dean >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [hidden email] >>>>> For additional commands, e-mail: [hidden email] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
||||||||
|
|
|
||||||||
|
|
Dean Yu wrote:
> I had gone ahead and filed a bug against JNA last night and Tim already > fixed it: > > https://jna.dev.java.net/issues/show_bug.cgi?id=135 Thanks. We'll wait for 3.2.4, then. > > -- Dean > > > On 10/29/09 2:19 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: > >> >> If you can tell me what url.getPath() was and what >> URLDecoder.decode(url.getPath()) is on this line, that would be very >> helpful. >> >> I believe the intention of this code is to get to the file that the URL >> is pointing to, and we need a bit more info to be able to suggest a fix >> to JNA. >> >> Dean Yu wrote: >>> I found the root of the problem. It's JNA, at >>> com.sun.jna.Native.loadNativeLibraryFromJar:705. It uses a URL to represent >>> the path to the shared library and calls URLDecoder.decode on it. I'm not >>> sure how this path is generated, but it's the value of java.io.tmpdir, which >>> is where the temporary shared library is copied into. It might be some MD5 >>> or something of my userID and I just got unlucky. >>> >>> -- Dean >>> >>> https://jna.dev.java.net/source/browse/jna/tags/3.2.2/jnalib/src/com/sun/jna >>> /Native.java?annotate=982 >>> >>> >>> On 10/27/09 6:28 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: >>> >>>> Dean Yu wrote: >>>>> Intel. >>>> >>>> OK, then there must be more to this than what I originally thought, >>>> because Intel Mac OS X is clearly supported. >>>> >>>> I'm curious why it comes up with weird path like this. Are we suspecting >>>> that somewhere in the remoting layer the path is messed up, causing >>>> System.load to be invoked with a wrong path name that doesn't exist? >>>> >>>>> >>>>> -- Dean >>>>> >>>>> >>>>> On 10/27/09 4:23 PM, "Kohsuke Kawaguchi" <[hidden email]> wrote: >>>>> >>>>>> >>>>>> Is this Intel Mac or PPC Mac? >>>>>> >>>>>> It looks like JNA doesn't have the proper binary for the platform in >>>>>> question. >>>>>> >>>>>> Dean Yu wrote: >>>>>>> I've been banging my head on this all day, and it's time to ask for some >>>>>>> help. I'm adding a test case to JUnitResultArchiverTest to validate that >>>>>>> some changes we're making don't break when the JUnit archiver is run on a >>>>>>> slave. Long story short, I'm calling FilePath.copyRecursiveTo to set up a >>>>>>> data set on the slave to archive from a test project. It works great on >>>>>>> Linux, but fails on a Mac: >>>>>>> >>>>>>> Caused by: java.lang.UnsatisfiedLinkError: Can't load library: >>>>>>> /var/folders/-S/-SC42LvtEC4VMYuErMwfOE >>>>>>> EpE/-Tmp-/hudson-remoting1332860957288863933.libjnidispatch.jnilib >>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1764) >>>>>>> at java.lang.Runtime.load0(Runtime.java:770) >>>>>>> at java.lang.System.load(System.java:1020) >>>>>>> at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) >>>>>>> at com.sun.jna.Native.loadNativeLibrary(Native.java:678) >>>>>>> at com.sun.jna.Native.<clinit>(Native.java:106) >>>>>>> at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:79) >>>>>>> at hudson.FilePath.readFromTar(FilePath.java:1724) >>>>>>> at hudson.FilePath.access$300(FilePath.java:157) >>>>>>> at hudson.FilePath$32.invoke(FilePath.java:1374) >>>>>>> at hudson.FilePath$32.invoke(FilePath.java:1371) >>>>>>> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052) >>>>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:104) >>>>>>> at hudson.remoting.UserRequest.perform(UserRequest.java:48) >>>>>>> at hudson.remoting.Request$2.run(Request.java:244) >>>>>>> >>>>>>> The spaces in the path are really + signs that got changed coming across >>>>>>> the >>>>>>> channel back to the master. If I catch the UnsatisfiedLinkError and print >>>>>>> the path on the remote side, the + signs show up, so I think the remote >>>>>>> side >>>>>>> has the right path. >>>>>>> >>>>>>> If I skip the chmod call in readFromTar, the test succeeds, but that's >>>>>>> obviously not the right solution. I tried to create a simple unit test to >>>>>>> add to FilePathTest to test copyRecursiveTo directly, but annoyingly, >>>>>>> that >>>>>>> passes. So it seems that the extra slave process in the middle alters >>>>>>> something. >>>>>>> >>>>>>> Anyone have any thoughts on what's going on? I've attached the two test >>>>>>> methods. Thanks. >>>>>>> >>>>>>> -- Dean >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [hidden email] >>>>>>> For additional commands, e-mail: [hidden email] >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [hidden email] >>>>> For additional commands, e-mail: [hidden email] >>>>> >>>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >> > > -- Kohsuke Kawaguchi Sun Microsystems http://weblogs.java.net/blog/kohsuke/ |
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
