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.
Created attachment 116385 [details] JVM crash report Product Version: NetBeans IDE 7.1.1 (Build 201203012225) Java: 1.6.0_31; Java HotSpot(TM) Client VM 20.6-b01 System: Linux version 3.0.0-12-generic running on i386; UTF-8; cs_CZ (nb) User directory: /home/cesilko/.netbeans/7.1.1 Cache directory: /home/cesilko/.netbeans/7.1.1/var/cache Description: ============ NetBeans IDE 7.1.1 constantly crashes when I want to commit a file to Subversion repository and save my username and password to my keyring. I am on Linux Mint 12 (Lisa) with Gnome 3 installed ~2 weeks ago. One of crash reports is attached. Steps to reproduce: =================== 1. Install NetBeans IDE 7.1.1 and JDK 6 Update 31 bundle. 2. Open "Window > Favorites" from main menu and "Add to Favorites..." some versioned folder e.g. https://svn.netbeans.org/svn/web-content/community. 3. Modify some file and invoke "Subversion > Commit..." from its popup menu. 4. Write some commit message and press "Commit". 5. When "Authentication failed" dialog opens, write your username and password and check "Save Username and Password" checkbox. 6. Push "Retry" button. IDE disappears immediately. [1] http://content.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-142931.html
Created attachment 116386 [details] Messages log file from some NetBeans session before the latest crash.
Jesse, please evaluate today.
Just reproduced it with JDK 7 Update 3 too.
I was not able to reproduce on Ubuntu 11.04 with keyring both locked and unlocked: Product Version: NetBeans IDE 7.1.1 (Build 201203012225) Java: 1.6.0_31; Java HotSpot(TM) Client VM 20.6-b01 System: Linux version 2.6.38-8-generic running on i386; UTF-8; en_US (nb) User directory: /home/tester/.netbeans/7.1.1 Cache directory: /home/tester/.netbeans/7.1.1/var/cache
I guess I can try to install Mint in VirtualBox. (I have Ubuntu but according to comment #4 this is not reproducible on that.) The log file contains nothing of interest, but could you please run "ant -f keyring.impl/build.xml test" on your machine to see if the crash is trivially reproducible?
No reason to think this is JDK-specific; probably some issue with the JNA bindings to the GNOME Keyring library. Bug #203735 does not result in a crash so that is probably unrelated. Bug #198921 does crash but that should already be fixed in 7.1. Bug #202515 might be a duplicate though that was on Ubuntu. Do you have a crash log?
Installed linuxmint-12-gnome-cd-nocodecs-32bit.iso in VirtualBox. Updated packages, upgraded to DVD edition, rebooted. GnomeProviderTest passed for me. Started 20120306-880e90fa5bd5 with JDK 7u3, registered deadlock.netbeans.org under Hudson builders, asked to start the faqsuck job, entered jglick plus password, saw password in seahorse, restarted IDE with -J-Dorg.netbeans.modules.keyring.level=FINEST, asked to start a different job, and login dialog had my password prefilled as expected and authentication succeeded.
Jesse, the crash log is attached to this bug. Did you see it? Also, what I have installed is linuxmint-12-gnome-dvd-64bit.iso not the 32bits version. My version of libgcrupt11 is 1.5.0-1, gnome-keyring is 3.2.2-0ubuntu0.1 and other versions of important gnome libraries are visible in the attached screenshot.
Created attachment 116417 [details] Screenshot of synaptic showing gnome filtered packages.
It works for me on Gentoo and Mint 64bit, but was able to reproduce with mint 32bit. Steps to reproduce: ------------------- 1. Install linuxmint-12-gnome-dvd-32bit.iso (for me this was in VMWare Fusion). 2. Update all the packages 3. Install jdk6, subversion and ssh 4. Download and install Netbeans7.1.1 5. Create local svn repo (svnadmin create /var/svn) 6. Do checkout of local repo using ssh+ssh 7. Fatal error on the same frame (in libgcrypt)
(In reply to comment #8) > the crash log is attached to this bug. Did you see it? Oh, in comment #0? Shows that gnome_keyring_item_create_sync causes the SEGV. > what I have > installed is linuxmint-12-gnome-dvd-64bit.iso not the 32bits version. Are you sure? Your messages.log says Operating System = Linux version 3.0.0-12-generic running on i386 Anyway comment #10 says it happens on 32-bit. Neither reporter seems to have run GnomeProviderTest like I asked.
*** Bug 202515 has been marked as a duplicate of this bug. ***
Created attachment 116441 [details] Ouput of "ant -f keyring.impl/build.xml test" command I am sorry Jesse, I overlooked the request in your comment #5. And yes, I am sure that I installed 64b Linux Mint. Just double checked on the installation DVD and also by uname command: cesilko@cesilko-nb1 ~ $ uname -a Linux cesilko-nb1 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux cesilko@cesilko-nb1 ~ $
OK, this is somewhat good news in that the crash is reproducible for someone in the controlled environment of the unit test. I presume it also shows C [libgcrypt.so.11+0x2abad] __float128+0x238ad j com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0 j com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315 j com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214 j com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341 j $Proxy41.gnome_keyring_item_create_sync(Ljava/lang/String;ILjava/lang/String;Lcom/sun/jna/Pointer;Ljava/lang/String;Z[I)I+52 j org.netbeans.modules.keyring.gnome.GnomeProvider.save(Ljava/lang/String;[CLjava/lang/String;)V+60 Now it is a matter of determining what in the environment triggers the problem. When you run seahorse, does your login keyring appear? Are there any keys in it? Bug #202515 comment #2 claims that the wrong version of libgcrypt11 somehow triggers this.
Test still passing for me in 32-bit Mint Lisa using both 6u31 and 7u3. (libcrypt11@1.5.0-1, gnome-keyring@3.2.2-0ubuntu0.1 like reporter; note that this includes the libgcrypt.so.11.7.0 which was claimed in bug #202515 to trigger the crash.) Perhaps installing the DVD ISO produces a different result than installing the CD ISO and upgrading to DVD edition? (Seems unlikely that this would matter for a core library such as libgcrypt.) Or reporters did not accept all available OS updates? Or there is some special setup option which changes how the login keyring is prepared? Or some other applications somehow modify the keyring in a way that the NB access code is not prepared for?
Trying again to reproduce according to ralphbenjamin's instructions: (In reply to comment #10) > 1. Install linuxmint-12-gnome-dvd-32bit.iso (for me this was in VMWare Fusion). Done in VirtualBox. Accepted default installation options: require a password to log in, and do not encrypt home dir. > 2. Update all the packages Done. > 3. Install jdk6 JRE 6u26 installed by default, but using JDK 6u31 (from a VBox shared folder). > subversion Done. > and ssh Installed by default, but I suppose you mean sshd (openssh-server). > 4. Download and install Netbeans7.1.1 Done. > 5. Create local svn repo (svnadmin create /var/svn) Done, in ~/svn. > 6. Do checkout of local repo using ssh+ssh From the IDE, I guess you mean, with "Save Username & Password" checked. > 7. Fatal error on the same frame (in libgcrypt) Working fine for me. After checking out the root of the new dir, NetBeansProjects under Home in Favorites was marked as SVN-modified. I made a new j2seproject and committed it, seeing in output window e.g. ==[IDE]== Mar 7, 2012 7:47:51 PM Checking out... checkout svn+ssh://localhost/home/jglick/svn/. -r HEAD --depth=infinity --force Checked out revision 0. ==[IDE]== Mar 7, 2012 7:47:53 PM Checking out... finished. After logging out and back in, I could continue to commit to this dir without reentering any password.
(In reply to comment #14) > OK, this is somewhat good news in that the crash is reproducible for someone in > the controlled environment of the unit test. I presume it also shows > Where should it be? The only similar line I've found in "SIGSEGV log" attached to bug #202515 is C [libgcrypt.so.11+0x2abad] gcry_md_unregister+0x238ad > When you run seahorse, does your login keyring appear? Are there any keys in > it? Not sure what exactly do you mean but when I run seahorse, there are login passwords that were saved in browser (credentials to websites).
Created attachment 116449 [details] Screenshot of my passwords and keys manager. This is my current keyring. Interestingly the second key has for some reason an empty password but maybe it's desired. Both "My Personal Keys" and "Other Keys" tabs are empty. I don't know if it matters but there is an error printed in the console when starting seahorese: cesilko@cesilko-nb1 ~ $ seahorse ** Message: init gpgme version 1.2.0 (seahorse:2794): GLib-GObject-CRITICAL **: Property 'icon' on class 'SeahorsePkcs11Certificate' has type 'gchararray' which is different from the type 'GIcon', of the property on interface 'GcrCertificateIface' cesilko@cesilko-nb1 ~ $
Created attachment 116450 [details] First page of "libcrypt" filtered out packages in Synaptic.
Created attachment 116451 [details] Second page of "libcrypt" filtered out packages in Synaptic.
(In reply to comment #17) > Where should it be? The only similar line I've found in "SIGSEGV log" attached > to bug #202515 is > > C [libgcrypt.so.11+0x2abad] gcry_md_unregister+0x238ad Yours also crashes inside gnome_keyring_item_create_sync, though apparently in a different subfunction. Possible it is unrelated, but hypothesizing it is the same. > when I run seahorse, there are login > passwords that were saved in browser (credentials to websites). Sure, that is normal (if you use Chrome at least). Just making sure that there _was_ a "login" keyring. (In reply to comment #18) > Interestingly the second key has for some reason an > empty password but maybe it's desired. Not sure, that is up to the subversion module, but anyway the keyring in my test Mint VM looks the same (minus the Derby password). > I don't know if it matters but there is an error printed in the console when > starting seahorese I get the same. (In reply to comment #19) > First page of "libcrypt" filtered out packages in Synaptic. libcrypt is unrelated AFAIK; all that ought to matter is the version of libgcrypt.so and the contents of the keyring (plus the versions of Java and NetBeans of course). Sorry, but without a way to reproduce I cannot do anything with this. A developer capable of reproducing (Ralph?), especially using the unit test, could - look for a trigger condition: incrementally delete keyring entries, or swap libgcrypt versions, or mix and match 32/64-bit kernels and VMs - play around with different ways of expressing the call to gnome_keyring_item_create_sync, e.g. other JNA idioms or using JNI - run GDB or valgrind and try to figure out at a low level what is going wrong
(In reply to comment #21) > Sorry, but without a way to reproduce I cannot do anything with this. A > developer capable of reproducing (Ralph?), especially using the unit test, > could > > - look for a trigger condition: incrementally delete keyring entries, or swap > libgcrypt versions, or mix and match 32/64-bit kernels and VMs I have an empty login keyring. Will try to change libgrcypt version later. > - play around with different ways of expressing the call to > gnome_keyring_item_create_sync, e.g. other JNA idioms or using JNI Will try to do this later. > - run GDB or valgrind and try to figure out at a low level what is going wrong Running the unit-test, gdb gives me: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x932feb70 (LWP 9880)] 0x0099ebad in do_aesni_enc_aligned ( a=0x9d7fb8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362?~Zx\253\t\245\021\275 ]\036\362\r\316ΦΌ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete s equence \343>, b=0x932fcef8 "9iK", ctx=0x932fccfc) at rijndael.c:710 710 rijndael.c: No such file or directory. in rijndael.c
(In reply to comment #21) > (In reply to comment #17) > > Where should it be? The only similar line I've found in "SIGSEGV log" attached > > to bug #202515 is > > > > C [libgcrypt.so.11+0x2abad] gcry_md_unregister+0x238ad > > Yours also crashes inside gnome_keyring_item_create_sync, though apparently in > a different subfunction. Possible it is unrelated, but hypothesizing it is the > same. I get the above error when using openjdk 6, the one with __float128 when I use sun jdk 6.
Quite consistently reproducible on Ubuntu 12.04 Beta(2) i386 + HotSpot JDK 1.6.0_31 32bit. The IDE is shut down right after it tries to access the native keyring.
I have not managed to reproduce a crash in Precise Pangolin b2 i386 / JDK 6u31. I have reproduced a failure to load the GNOME keyring provider at all, filed as bug #211401 and fixed.
Tested a dev build on 12.04; after the fix for #211401, keyring integration seems to work fine: started a Hudson job using a login, restarted IDE, asked to start another job, and dialog correctly remembered my password. ant -f keyring.impl test also works (with both JDK 6 and 7). Did notice that seahorse does not list any passwords in the login keyring - does not even display an expand handle for the "login" node. Still, the passwords are being remembered. And even if you use File > New to add a password manually, the display is the same. So I think this may just be a seahorse bug.
Maybe dupe of bug #211463?
Not in my case, unfortunately. I am running 32bit JVM on a 32bit OS. I even tried downgrading the libgcrypt library to the previous version but without much success. Still crashing, though on a different offset. I will try with Ubuntu 12.04 Final once it is released to see what happens. (In reply to comment #27) > Maybe dupe of bug #211463?
Is seahorse able to display your login keyring? Given the difficulty in reproducing crashes like this, I keep wondering whether particular contents of the keyring trigger the problem. (Although comment #22 implies that this is not the issue.)
FYI, see my comments in bug #211463. I am glad to confirm that the latest dev build does neither crash when saving password to the keyring nor when opening web application! Product Version: NetBeans IDE Dev (Build 201204220400) Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 System: Linux version 3.0.0-12-generic running on amd64; UTF-8; cs_CZ (nb) User directory: /home/cesilko/.netbeans/dev Cache directory: /home/cesilko/.cache/netbeans/dev
Seahorse was able to display the login keyring ok. I've resolved the problem by deleting the login keyring and creating a new one. Everything seems to work fine so far... (In reply to comment #29) > Is seahorse able to display your login keyring? Given the difficulty in > reproducing crashes like this, I keep wondering whether particular contents of > the keyring trigger the problem. (Although comment #22 implies that this is not > the issue.)
(In reply to comment #31) > I've resolved the problem by deleting the login keyring and creating a new one. Resolved with the same IDE build and JDK? If so, did you keep a copy of the original keyring for diagnosis by bisection?
(In reply to comment #32) > (In reply to comment #31) > > I've resolved the problem by deleting the login keyring and creating a new one. > > Resolved with the same IDE build and JDK? If so, did you keep a copy of the > original keyring for diagnosis by bisection? The same IDE build and JDK. Sorry, the keyring got lost :(