Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 211655 - There is an incompatible JNA native library installed on this system.
There is an incompatible JNA native library installed on this system.
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
7.2
PC Linux
: P1 with 1 vote (vote)
: 7.2
Assigned To: Stanislav Aubrecht
issues@platform
7.2Beta-stopper-fixed
:
: 211591 211599 211600 211664 211818 214383 214725 (view as bug list)
Depends on:
Blocks: 211403
  Show dependency treegraph
 
Reported: 2012-04-24 16:26 UTC by hanasaki
Modified: 2012-10-10 07:34 UTC (History)
14 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hanasaki 2012-04-24 16:26:37 UTC
not an issue in : netbeans-trunk-nightly-201204181547-ml.zip
has been an issue since a few days ago.
no change in system or java version only netbeans version
using the zip netbeans-trunk-nightly-201204181547-ml.zip the error does not happen on my current system.

java -version
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu2)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

uname -a
Linux usa 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


===
SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.netbeans.modules.masterfs.Installer
java.lang.Error: 

There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
 - remove or uninstall the offending library
 - set the system property jna.nosys=true
 - set jna.boot.library.path to include the path to the version of the 
   jnidispatch library included with the JNA jar file you are using

        at com.sun.jna.Native.<clinit>(Native.java:142)
        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:525)
        at java.lang.Class.newInstance0(Class.java:372)
        at java.lang.Class.newInstance(Class.java:325)
        at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
        at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
        at org.netbeans.modules.masterfs.watcher.Watcher.getNotifierForPlatform(Watcher.java:414)
        at org.netbeans.modules.masterfs.watcher.Watcher.<init>(Watcher.java:85)
        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:525)
        at java.lang.Class.newInstance0(Class.java:372)
        at java.lang.Class.newInstance(Class.java:325)
        at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
        at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
        at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:421)
        at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:216)
        at org.netbeans.modules.masterfs.watcher.Watcher.ext(Watcher.java:89)
        at org.netbeans.modules.masterfs.watcher.Watcher.isEnabled(Watcher.java:95)
        at org.netbeans.modules.masterfs.Installer.run(Installer.java:54)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032)
Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to
        at org.openide.util.RequestProcessor.post(RequestProcessor.java:424)
        at org.netbeans.core.startup.NbStartStop.initialize(NbStartStop.java:87)
        at org.netbeans.core.startup.NbInstaller.classLoaderUp(NbInstaller.java:333)
        at org.netbeans.ModuleManager.enable(ModuleManager.java:1149)
        at org.netbeans.ModuleManager.enable(ModuleManager.java:986)
        at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:340)
        at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:276)
        at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:295)
        at org.netbeans.core.startup.Main.getModuleSystem(Main.java:169)
        at org.netbeans.core.startup.Main.start(Main.java:305)
        at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:123)
[catch] at java.lang.Thread.run(Thread.java:722)
WARNING [org.netbeans.core.modules]: the modules [org.netbeans.modules.db.sql.editor, org.netbeans.modules.editor.structure, org.netbeans.modules.xml.text] use org.netbeans.modules.editor.deprecated.pre65formatting which is deprecated.
...
Comment 1 Jaroslav Tulach 2012-04-25 09:42:05 UTC
I expect the problems are result of

changeset:   219696:836f5c2762c5
parent:      219569:5b2c1d79a577
user:        S. Aubrecht <saubrecht@netbeans.org>
date:        Fri Apr 20 11:34:55 2012 +0200
summary:     #211403 - upgrading JNA to 3.4.0
Comment 2 Stanislav Aubrecht 2012-04-25 09:52:15 UTC
Isn't this caused by the fact that previous version of JNA module extracted its OS native binaries to user dir and the new version of JNA module did not overwrite them?
Did you try starting the IDE with a clean user dir?
Comment 3 hanasaki 2012-04-25 14:57:17 UTC
saubrecht, I believe the below addresses the suggestion and shows there is still an issue.  Feel free to email me directly if there is a specific directory to address that I am missing.

==
removed the only jna like directory under ~
  ./.visualvm/1.3/var/cache/jna  <= which was empty

for nightly builds - I have a general practice of:
- use the zip installer
- rm -rf netbeans <= the unzip file and dir
- rm -rf ~/.netbeans
- unzip the new nightly
- run from bash and accept the license

This process is the result of new nightly releases often resulting in broken modules.
Comment 4 Stanislav Aubrecht 2012-04-25 15:11:14 UTC
Reporter, please search your system for libjnidispatch.so library, thanks.
Comment 5 Jaroslav Tulach 2012-04-25 15:14:27 UTC
*** Bug 211599 has been marked as a duplicate of this bug. ***
Comment 6 hanasaki 2012-04-25 16:19:03 UTC
saubrecht, found below
  /usr/lib/jni/libjnidispatch.so
Comment 7 Stanislav Aubrecht 2012-04-26 07:09:40 UTC
(In reply to comment #6)
> saubrecht, found below
>   /usr/lib/jni/libjnidispatch.so

OK, try running NetBeans with -J-Djna.nosys=true
Comment 8 hanasaki 2012-04-26 15:53:44 UTC
The command line option below results in no JNA related stack traces or exceptions.  What is the operational impact of this option?  Shall this be considered a short term workaround with the JNA issue still to be resolved?
-J-Djna.nosys=true
Comment 9 Jesse Glick 2012-04-26 18:19:34 UTC
The question is why the presence of $NB/platform/modules/lib/amd64/Linux/libjnidispatch.so does not suffice; our copy of JNA should not even be considering /usr/lib/jni/libjnidispatch.so.
Comment 10 hanasaki 2012-04-26 18:34:51 UTC
the below libraries also exist:
Netbeans unzip top level directory:
./netbeans/platform/modules/lib/i386/Linux/libjnidispatch.so
./netbeans/platform/modules/lib/amd64/Linux/libjnidispatch.so

1. not sure which one NB picks up or how it is determined.
2. this is the openjdk7 from Ubuntu "precise" - replacing the current nightly with the unzip from several days ago still functions without the jna issue.
* unfortunately, I do not have access to try with the Oracle java7... This should not have any impact... should it?

FYI:
uname -a
Linux usa 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 11 Marian Mirilovic 2012-04-27 11:39:10 UTC
*** Bug 211600 has been marked as a duplicate of this bug. ***
Comment 12 Marian Mirilovic 2012-04-27 11:41:47 UTC
*** Bug 211591 has been marked as a duplicate of this bug. ***
Comment 13 Marian Mirilovic 2012-04-27 12:36:54 UTC
Stopper for Beta
Comment 14 Marian Mirilovic 2012-04-27 12:40:25 UTC
*** Bug 211664 has been marked as a duplicate of this bug. ***
Comment 15 Michel Graciano 2012-04-27 12:45:28 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > saubrecht, found below
> >   /usr/lib/jni/libjnidispatch.so
> 
> OK, try running NetBeans with -J-Djna.nosys=true

It works as a workaround for me too.
Comment 16 Stanislav Aubrecht 2012-04-27 15:09:16 UTC
core-main 6848495bad4f
Comment 17 Antonin Nebuzelsky 2012-04-27 15:44:16 UTC
Stando, backport to release72_beta as well. Thanks.
Comment 18 Marian Mirilovic 2012-04-27 16:03:12 UTC
*** Bug 211818 has been marked as a duplicate of this bug. ***
Comment 19 Stanislav Aubrecht 2012-04-27 16:16:59 UTC
in release72_beta branch as 17840f7bcdfa
Comment 20 hanasaki 2012-04-27 16:17:41 UTC
What was the cause?  What was the resolution?
Comment 21 Michel Graciano 2012-04-27 16:24:35 UTC
(In reply to comment #20)
> What was the cause?  What was the resolution?

http://hg.netbeans.org/core-main/rev/6848495bad4f
Comment 22 Jesse Glick 2012-04-27 16:48:00 UTC
The cause - JNA by default tries System.loadLibrary("jnidispatch"), falling back to unpacking and loading a bundled copy of this library which is a little slower. For speed we do distribute the unpacked library in NB, which is normally fine. But if it is also in /usr/lib, apparently that gets loaded preferentially. JNA 3.4 detects this problem and signals an error for it (seems 3.2.7 would have just proceeded, possibly causing runtime errors later).

The resolution - early during NB startup, set a system property instructing JNA to load "jninbdispatch" instead, renaming the unpacked DLLs included with the NB module accordingly. No library of this name would be expected in /usr/lib or the like, so it is sure to be loaded from the intended location in the NB installation.
Comment 23 Quality Engineering 2012-05-01 09:53:47 UTC
Integrated into 'main-golden', will be available in build *201205010400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6848495bad4f
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders
Comment 24 Marian Mirilovic 2012-05-02 08:07:15 UTC
(In reply to comment #19)
> in release72_beta branch as 17840f7bcdfa

Standa, I do not see this changeset in repository
Comment 25 Marian Mirilovic 2012-05-02 08:15:33 UTC
Found that finally : 
http://hg.netbeans.org/releases/rev/17840f7bcdfa
Comment 26 Quality Engineering 2012-05-03 00:39:58 UTC
Integrated into 'releases', will be available in build *201205021516* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/17840f7bcdfa
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders
(transplanted from 6848495bad4fc64c7f7e2b363cb13b002b041e8f)
Comment 27 yuriy_lalym 2012-05-03 20:28:37 UTC
Product Version: NetBeans IDE Dev (Build 201205030400)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Linux version 3.3.4-22-desktop running on i386; UTF-8; en_US (nb)

java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
	at org.netbeans.modules.masterfs.watcher.linux.LinuxNotifier.<init>(LinuxNotifier.java:103)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
[catch] at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
	at org.netbeans.modules.masterfs.watcher.Watcher.getNotifierForPlatform(Watcher.java:417)
	at org.netbeans.modules.masterfs.watcher.Watcher.<init>(Watcher.java:85)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
	at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1041)
	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1021)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeSingleResult(ProxyLookup.java:1249)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeDelegate(ProxyLookup.java:1091)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.access$900(ProxyLookup.java:1021)
	at org.openide.util.lookup.ProxyLookup$LazyCollection$1.hasNext(ProxyLookup.java:1215)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem$StatusImpl.resultChanged(FileBasedFileSystem.java:305)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem$StatusImpl.<init>(FileBasedFileSystem.java:271)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<init>(FileBasedFileSystem.java:81)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<clinit>(FileBasedFileSystem.java:79)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedURLMapper.getFileObjects(FileBasedURLMapper.java:138)
	at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:65)
	at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:212)
	at org.netbeans.modules.project.ui.LazyProject.getProjectDirectory(LazyProject.java:92)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList$4.run(OpenProjectList.java:1537)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList$4.run(OpenProjectList.java:1505)
	at org.openide.util.Mutex.readAccess(Mutex.java:290)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList.load(OpenProjectList.java:1505)
	at org.netbeans.modules.project.ui.OpenProjectList$2.run(OpenProjectList.java:215)
	at org.netbeans.modules.project.ui.OpenProjectList$2.run(OpenProjectList.java:208)
	at org.openide.util.Mutex.readAccess(Mutex.java:290)
	at org.netbeans.modules.project.ui.OpenProjectList.getDefault(OpenProjectList.java:208)
	at org.netbeans.modules.project.ui.OpenProjectsTrampolineImpl.addPropertyChangeListenerAPI(OpenProjectsTrampolineImpl.java:95)
	at org.netbeans.api.project.ui.OpenProjects.addPropertyChangeListener(OpenProjects.java:287)
	at org.netbeans.api.project.ui.OpenProjects.<init>(OpenProjects.java:98)
	at org.netbeans.api.project.ui.OpenProjects.<clinit>(OpenProjects.java:90)
	at org.netbeans.modules.editor.bookmarks.BookmarksPersistence.initProjectsListening(BookmarksPersistence.java:105)
	at org.netbeans.modules.editor.bookmarks.EditorBookmarksModule.restored(EditorBookmarksModule.java:77)
	at org.netbeans.core.startup.NbInstaller.loadCode(NbInstaller.java:450)
	at org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:383)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1177)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1000)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:340)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:276)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:295)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:169)
	at org.netbeans.core.startup.Main.start(Main.java:305)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:123)
	at java.lang.Thread.run(Unknown Source)
Comment 28 Michel Graciano 2012-05-03 21:04:21 UTC
For me it is fixed.

Product Version: NetBeans IDE Dev (Build 201205030400)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Linux version 3.0.0-17-generic-pae running on i386; UTF-8; en_US (nb)
Comment 29 Jesse Glick 2012-05-03 21:39:02 UTC
yuriy_lalym - if you encounter problems please file fresh bug reports, as your issue may not even be related. In fact the stack trace you pasted in (BTW please use attachments instead) does not contain the root cause, i.e. the reason why the class could not be initialized. This would be in your messages.log, which gets attached to a bug automatically if you use the IDE's Exception Reporter.
Comment 30 Marian Mirilovic 2012-05-25 08:24:25 UTC
*** Bug 212977 has been marked as a duplicate of this bug. ***
Comment 31 Marian Mirilovic 2012-05-25 08:25:30 UTC
See issue 212977 - it's from NB 7.2 Beta
Comment 32 Stanislav Aubrecht 2012-05-25 08:35:48 UTC
Let's leave this issue closed for the moment, issue #212977 just reports that JNA initialization failed. But there's no message.log attached to it so I can't evaluate the root cause (which could be different from this issue).
Comment 33 bhaskar.vk 2012-05-30 16:34:13 UTC
This could happen if there is already a  "/tmp/jna" directory present, and not owned by the user starting the netbeans instance.
The jna library is extracted in directory pointed by 'java.io.tmpdir' system property, which on Unix is /tmp by default.
This is a problem when multiple users are concerned, as only one can own the '/tmp/jna' directory.

To fix it, instead of the recommended '-J-Djna.nosys=true', try '-J-Djava.io.tmpdir=$HOME' , so that the jna directory gets created in the user's home directory.

Using '-J-Djava.io.tmpdir=$HOME' helped me solve the issue on my box.
Comment 34 Jesse Glick 2012-05-30 20:37:05 UTC
(In reply to comment #33)
> if there is already a  "/tmp/jna" directory present, and not
> owned by the user starting the netbeans instance.

See bug #212938.
Comment 35 Marian Mirilovic 2012-06-19 07:51:14 UTC
*** Bug 214383 has been marked as a duplicate of this bug. ***
Comment 36 Marian Mirilovic 2012-06-25 21:36:23 UTC
*** Bug 214725 has been marked as a duplicate of this bug. ***
Comment 37 Quality Engineering 2012-10-10 07:34:52 UTC
Integrated into 'releases', will be available in build *201210100002* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/17840f7bcdfa
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders
(transplanted from 6848495bad4fc64c7f7e2b363cb13b002b041e8f)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo