This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The following exception appears in the messages log when IDE is starting on Sparc-Linux machine. INFO [org.openide.util.lookup.MetaInfServicesLookup]: Cannot create class org.netbeans.modules.masterfs.watcher.linux.LinuxNotifier java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/linux-sparcv9/libjnidispatch.so) not found in resource path (/ws/ntrunk/builds/trunk/biweekly/build22.0/sparc-Linux/install/lib/netbeans/platform/lib/boot.jar:/ws/ntrunk/builds/trunk/biweekly/build22.0/sparc-Linux/install/lib/netbeans/platform/lib/org-openide-modules.jar:/ws/ntrunk/builds/trunk/biweekly/build22.0/sparc-Linux/install/lib/netbeans/platform/lib/org-openide-util.jar:/ws/ntrunk/builds/trunk/biweekly/build22.0/sparc-Linux/install/lib/netbeans/platform/lib/org-openide-util-lookup.jar:/ws/ntrunk/builds/trunk/biweekly/build22.0/sparc-Linux/install/lib/netbeans/platform/lib/org-openide-util-ui.jar:/ws/ntrunk/tools/JDK/sparc-Linux/jdk1.7.0_80/lib/dt.jar:/ws/ntrunk/tools/JDK/sparc-Linux/jdk1.7.0_80/lib/tools.jar) at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:776) at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:736) at com.sun.jna.Native.<clinit>(Native.java:131) at org.netbeans.modules.masterfs.watcher.linux.LinuxNotifier.<init>(LinuxNotifier.java:103) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:383) at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64) [catch] at org.openide.util.lookup.MetaInfServicesLookup$Item.getInstance(MetaInfServicesLookup.java:514) at org.netbeans.modules.masterfs.watcher.Watcher.getNotifierForPlatform(Watcher.java:476) at org.netbeans.modules.masterfs.watcher.Watcher.<init>(Watcher.java:86) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:383) at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64) at org.openide.util.lookup.MetaInfServicesLookup$Item.getInstance(MetaInfServicesLookup.java:514) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:422) at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:222) at org.netbeans.modules.masterfs.watcher.Watcher.ext(Watcher.java:90) at org.netbeans.modules.masterfs.watcher.Watcher.isEnabled(Watcher.java:96) at org.netbeans.modules.masterfs.Installer.run(Installer.java:54) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
Please, what is the expected behavior? If NetBeans is run on platform that does not support native file listeners (JNA library does not contains binaries for linux-sparc), it logs an info message and native filesystem watcher is disabled. It seems that the situation is handled correctly.
(In reply to Jaroslav Havlin from comment #1) > Please, what is the expected behavior? > > If NetBeans is run on platform that does not support native file listeners > (JNA library does not contains binaries for linux-sparc), it logs an info > message and native filesystem watcher is disabled. It seems that the > situation is handled correctly. If platform is not supported, an IDE should not print INFO in log. If platform is supported and there is no native library, an IDE should print INFO in log.
(In reply to Jaroslav Havlin from comment #1) > Please, what is the expected behavior? The best solution is add supported platform Linux-Sparc (if it is possible). I looked at the header sys/inotify.h in Linux-Sparc. It is exactly same as Linux-x86.
(In reply to Alexander Simon from comment #2) > If platform is not supported, an IDE should not print INFO in log. > If platform is supported and there is no native library, an IDE should print > INFO in log. But maybe the user (or somehow who needs to read IDE Log and identify possible causes of some problem) should know that native file listeners do not work and why. I think that P1 is quite a high priority for an extra log message, so I'm decreasing it. (In reply to Alexander Simon from comment #3) > The best solution is add supported platform Linux-Sparc (if it is possible). > I looked at the header sys/inotify.h in Linux-Sparc. It is exactly same as > Linux-x86. We would probably need to add support for linux-sparc to JNA library, which we depend on when using native APIS. I don't know if it is possible or how difficult it would be.
P1 because corresponded bug has severity S2. S2 fits P1. Please, reconcile priority with author of CR_21799096.
> P1 because corresponded bug has severity S2. I understand now, thank you. Would this solution be acceptable: - Print the error message and stack-trace with log level FINE. - Print simple message "Native file watcher is disabled" with log level INFO. So we (or the users) will know that native watcher is disabled, and the log level can be configured if more details are needed. Comment from the original bug report: > The following exception appears in the messages log when IDE, dbxtool or > code-analyzer is starting on Sparc-Linux machine. Code-analyzer hangs in > that case. I'm not sure that hanging of code-analyzer is related to the logged error. I guess it is an independent issue. Do we have some thread dump or other info?
Hi, execution of find netbeans -name libjni* gives netbeans/platform/modules/lib/i386/linux/libjnidispatch-410.so netbeans/platform/modules/lib/libjnidispatch-410.jnilib netbeans/platform/modules/lib/amd64/linux/libjnidispatch-410.so So I expect there should be an appropriate libjnidispatch.so for sparc-Linux platform as well. Studio components testing on sparc-Linux platform is now a high priority task for Studio QA team so that the original bug has S2 priority. I think CodeAnalyzer hanging is a different issue and I will attach threads dump to the original CR.
Hello, (In reply to Alexander Pepin from comment #7) > find netbeans -name libjni* > gives > netbeans/platform/modules/lib/i386/linux/libjnidispatch-410.so > ... > So I expect there should be an appropriate libjnidispatch.so for sparc-Linux > platform as well. These files are extracted from libs.jna/external/jna-4.1.0.jar (resp. nbbuild/netbeans/platform/modules/ext/jna-4.1.0.jar) and renamed. See libs.jna/nbproject/project.properties. Command "jar -tf nbbuild/netbeans/platform/modules/ext/jna-4.1.0.jar | grep .so" shows that there is no .so library for linux-sparc variant. Combinations of OS and architecture supported by JNA can be found here: https://github.com/java-native-access/jna/tree/master/lib/native Sparc processors seem to be supported only with SunOS.
> Would this solution be acceptable: > - Print the error message and stack-trace with log level FINE. > - Print simple message "Native file watcher is disabled" with log level INFO. Fixed in http://hg.netbeans.org/core-main/rev/f2309d2d8529. Please verify. I think that this workaround fixes the actual bug, and that we can close it. Adding support for sparc-linux is a different issue, and rather enhancement. Thank you.
(In reply to Jaroslav Havlin from comment #9) > > Would this solution be acceptable: > > - Print the error message and stack-trace with log level FINE. > > - Print simple message "Native file watcher is disabled" with log level INFO. > Fixed in http://hg.netbeans.org/core-main/rev/f2309d2d8529. > Please verify. > > I think that this workaround fixes the actual bug, and that we can close it. > Adding support for sparc-linux is a different issue, and rather enhancement. > > Thank you. Hi Jaroslav, Workaround is fine. I would prefer to downgrade the issue to P3 and keep it opening. Let the issue track a progress of delivering of native library for Linux-Sparc. Alexander
Created attachment 156172 [details] native library patch preview
How did you build the .so lib for sparc? Is it now an official part of the jna jar? Or did you just grab the sources and rebuilt on sparc? If not part of the official release then how will we upgrade jna? We will not be able to upgrade jna ourselves without the cnd team rebuilding on sparc.
> I would prefer to downgrade the issue to P3 and keep it opening. Sure.
(In reply to Ondrej Vrabec from comment #12) > How did you build the .so lib for sparc? Is it now an official part of the > jna jar? Or did you just grab the sources and rebuilt on sparc? > If not part of the official release then how will we upgrade jna? We will > not be able to upgrade jna ourselves without the cnd team rebuilding on > sparc. Hi, Of course it is a fix preview (not official fix). To get fix I: - cloned repository trunk (#git clone https://github.com/java-native-access/jna.git) - fixed a build.xml and test/com/sun/jna/PlatformTest.java - built project on Linux-Sparc (#ant) - get production in dist/jna.jar I tested fix on Linux-Sparc and it works. Alexander
(In reply to Alexander Simon from comment #14) > (In reply to Ondrej Vrabec from comment #12) > > How did you build the .so lib for sparc? Is it now an official part of the > > jna jar? Or did you just grab the sources and rebuilt on sparc? > > If not part of the official release then how will we upgrade jna? We will > > not be able to upgrade jna ourselves without the cnd team rebuilding on > > sparc. > > Hi, > > Of course it is a fix preview (not official fix). To get fix I: > - cloned repository trunk (#git clone > https://github.com/java-native-access/jna.git) > - fixed a build.xml and test/com/sun/jna/PlatformTest.java > - built project on Linux-Sparc (#ant) > - get production in dist/jna.jar > > I tested fix on Linux-Sparc and it works. > > Alexander All jna test are passed, except: [junit] Testsuite: com.sun.jna.LibraryLoadTest [junit] Tests run: 23, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.209 sec [junit] [junit] Testcase: testLoadLibraryWithUnicodeName(com.sun.jna.LibraryLoadTest): FAILED [junit] Library 'lib?????.so' at /tmp/jna--905066581/lib?????.so could not be loaded: java.lang.UnsatisfiedLinkError: /tmp/jna--905066581/lib?????.so: cannot open shared object file: No such file or directory [junit] junit.framework.AssertionFailedError: Library 'lib?????.so' at /tmp/jna--905066581/lib?????.so could not be loaded: java.lang.UnsatisfiedLinkError: /tmp/jna--905066581/lib?????.so: cannot open shared object file: No such file or directory [junit] at com.sun.jna.LibraryLoadTest.testLoadLibraryWithUnicodeName(LibraryLoadTest.java:163) It seems this test is related OS setup and do not tell against library. Alexander
Created attachment 156174 [details] proposed patch for native code
Created attachment 156175 [details] proposed new native library
Created issue on the GitHub: https://github.com/java-native-access/jna/issues/503
Created pull request: https://github.com/java-native-access/jna/pull/504
Integrated into 'main-silver', will be available in build *201509160002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/f2309d2d8529 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #255079: Print stack-trace with level FINE if native library for file watcher is not available
JNA library update: - the Linux-Sparc fix was integrated in JNA trunk.
JNA with linux-sparcv9.jar is available in: https://github.com/java-native-access/jna/archive/4.2.1.tar.gz Could you start integration process?
(In reply to Alexander Simon from comment #22) > JNA with linux-sparcv9.jar is available in: > https://github.com/java-native-access/jna/archive/4.2.1.tar.gz > > Could you start integration process? Makes sense for 8.2.
Updated to 4.2.1 http://hg.netbeans.org/jet-main/rev/907a2714b40c
JNA version 4.2.1 has a bug that prevents it from working properly on linux/unix machines, thus the commit for this issue has now created a new bug: https://netbeans.org/bugzilla/show_bug.cgi?id=258383 Please use a patched version of 4.2.1 with fix from commit https://github.com/java-native-access/jna/pull/549.
Patched jna-4.2.1 http://hg.netbeans.org/jet-main/rev/e28db4eaf08a
Integrated into 'main-silver', will be available in build *201603170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e28db4eaf08a User: Milutin Kristofic <mkristofic@netbeans.org> Log: #255079 - Update JNA to 4.2.1 - patched
*** Bug 258383 has been marked as a duplicate of this bug. ***
*** Bug 258367 has been marked as a duplicate of this bug. ***
Integrated into 'main-silver', will be available in build *201603310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/601758883a58 User: Milutin Kristofic <mkristofic@netbeans.org> Log: #255079 - Update JNA to 4.2.1 - to 4.2.2