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.
Product Version = NetBeans IDE Dev (Build 201004060201) Operating System = Linux version 2.6.31-20-generic running on amd64 Java; VM; Vendor = 1.6.0_15 Runtime = Java HotSpot(TM) 64-Bit Server VM 14.1-b02 I already sent two reports: http://statistics.netbeans.org/analytics/detail.do?id=167696 and pointed out that problem could be related to http://netbeans.org/bugzilla/show_bug.cgi?id=183581
see the exception report at http://statistics.netbeans.org/analytics/detail.do?id=167696 ... i hope keyring issues belong under platform/Options&Settings
Don't know how to reproduce, but can at least avoid the NPE and print a diagnostic warning when this situation occurs that might assist in a better fix later: core-main #1a710d221c0a
Created attachment 96946 [details] exception report
Created attachment 96947 [details] IDE messages log
Please let me know if and how can I help you to reproduce the problem. It's nice that it works for you but is is quite annoying for me. :)
Problem is not present in build 201004030201. There where no Ubuntu updates related to keyring since April 3rd. I did not make any changes to system configuration. Having above in mind I am reopening this bug and since the problem is blocking my daily workflow setting priority to P2. Feedback on the topic from other Ubuntu users will be highly appreciated!
Please wait for the changeset I mentioned to actually appear in dev builds before commenting further - your last stack trace precedes the fix. BTW I am an Ubuntu user, though using 32-bit for now which might be relevant.
I am sorry. I did wait on todays build before commenting. It seams that I misinterpreted Michel explanation. I have understood that if changeset is merged in the main repository it will be included in the next build. http://hg.netbeans.org/main/rev/1a710d221c0a
(In reply to comment #8) > if changeset is > merged in the main repository it will be included in the next build. > http://hg.netbeans.org/main/rev/1a710d221c0a 1. http://hg.netbeans.org/main/ is just a random team repository, it is nothing special. http://hg.netbeans.org/main-silver/ is where changesets from team repositories are merged into. 2. Presence in main-silver _does_ mean it will be included in the next daily build. That build apparently has not run yet. When it does, and it gets uploaded, an automated comment gets added to the issue (so long as the changeset comment mentions an issue number).
(In reply to comment #7) > I am an Ubuntu user, though using 32-bit for now which might be relevant. Just double-checked on Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP <Oct 16...> x86_64 and the keyring seemed to be working OK. If you go to Applications > Accessories > Passwords and Encryption Keys, are the expected passwords there?
Although there is no message about integrating #1a710d221c0a in dev build since 201004100201 I am not experiencing mentioned problem. versioning.subversion.d8:52:19:33:87:a3:e6:6f:ac:5c:b5:52:4a:76:c1:9a:0f:11:0d:04 key is present but password appears to be empty. There is a bunch of similar keys and non of those have password except one. Could it be a problem with importing previous settings? Shall I try clean install? Latest log using todays build: FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.d8:52:19:33:87:a3:e6:6f:ac:5c:b5:52:4a:76:c1:9a:0f:11:0d:04 FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.cert.d8:52:19:33:87:a3:e6:6f:ac:5c:b5:52:4a:76:c1:9a:0f:11:0d:04 WARNING [org.netbeans.modules.keyring.gnome.GnomeProvider]: #183670: GnomeKeyringFound.secret == null FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.d4:b9:14:02:1a:a9:43:5a:c9:57:8c:bf:dd:5a:41:50:80:ec:8a:bd FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.cert.d4:b9:14:02:1a:a9:43:5a:c9:57:8c:bf:dd:5a:41:50:80:ec:8a:bd WARNING [org.netbeans.modules.keyring.gnome.GnomeProvider]: #183670: GnomeKeyringFound.secret == null FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.d8:52:19:33:87:a3:e6:6f:ac:5c:b5:52:4a:76:c1:9a:0f:11:0d:04 FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.cert.d8:52:19:33:87:a3:e6:6f:ac:5c:b5:52:4a:76:c1:9a:0f:11:0d:04 WARNING [org.netbeans.modules.keyring.gnome.GnomeProvider]: #183670: GnomeKeyringFound.secret == null FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.d4:b9:14:02:1a:a9:43:5a:c9:57:8c:bf:dd:5a:41:50:80:ec:8a:bd FINEST [org.netbeans.modules.keyring]: reading: versioning.subversion.cert.d4:b9:14:02:1a:a9:43:5a:c9:57:8c:bf:dd:5a:41:50:80:ec:8a:bd WARNING [org.netbeans.modules.keyring.gnome.GnomeProvider]: #183670: GnomeKeyringFound.secret == null WARNING [org.netbeans.core.TimableEventQueue]: too much time in AWT thread org.netbeans.core.ui.sampler.SelfSamplerAction$Controller@5f3f6ca0
(In reply to comment #11) > Although there is no message about integrating #1a710d221c0a in dev build Indeed, I am not sure why. AFAIK new dev builds should have this fix. > versioning.subversion.... key is present but password appears to be empty. Interesting. I cannot reproduce any warning when explicitly saving an empty password - so it would seem that in your case the keyring entry does not merely have an empty password, but is somehow corrupt. > Could it be a problem with importing previous settings? No idea. > Shall I try clean install? A clean installation of NetBeans will have no effect, since the possibly damaged keyring entries are in your GNOME Keyring. > GnomeKeyringFound.secret == null The API docs make no mention of this being a possibility. I can find C code such as secret = found->secret ? g_strdup (found->secret) : NULL; but whether this is based on a real condition or just paranoia I don't know. (Other C code does not do a null check on the secret struct field.) Anyway #1a710d221c0a should reduce the problem to a warning in the log. You should be able to delete the problematic entries from the Seahorse GUI mentioned in my last comment.
In short you think it's a Ubuntu problem. I will delete all keys with empty passwords and see what will happen. :) Perhaps it's not relevant but I did not have any problems using SVN from command line. Authentication is working correctly. schkovich@schkovich:~$ cd NetBeansProjects/dev/LazyLoad schkovich@schkovich:~/NetBeansProjects/dev/LazyLoad$ svn commit -m "Removing isLeaf check from Stores_Ini class" Sending Lib/Stores/Ini.php Transmitting file data . Committed revision 57. schkovich@schkovich:~/NetBeansProjects/dev/LazyLoad$
(In reply to comment #13) > In short you think it's a Ubuntu problem. I believe so, though it's just a guess at this point. > I did not have any problems using SVN from command line. With the keys that appear to have empty passwords? The CLI svn client may be using plaintext passwords in ~/.subversion/auth/ rather than the GNOME Keyring (you could confirm using strace).
After deleting keys with empty password there is no warning message in messages.log
Created attachment 97236 [details] latest messages.log messages.log after deleting keys with empty password
Created attachment 97237 [details] svn trace svn trace log
(In reply to comment #14) > The CLI svn client may be using plaintext passwords in ~/.subversion/auth/ Confirmed, which would explain why it is not affected. Naturally if you have any idea how the corrupt entries got added to the keyring in the first place, that would be useful information.
Absolutely, that is the question. All we can do is wait on it to happen again. :) I will be checking keys and logs after each nightly build installation. I have doubts about importing settings. Is there any chance that adding fingerprint authorization could mess up keys? Thank you for assistance. Goran
(In reply to comment #19) > I will be checking keys and logs after each nightly build installation. Thank you, your help in diagnosing is much appreciated. > Is there any chance that adding fingerprint authorization could mess up keys? It sounds plausible.
I just got a sequence of thirty or so of these warnings WARNING [org.netbeans.modules.keyring.gnome.GnomeProvider]: #183670: GnomeKeyringFound.secret == null after performing a Subversion operation (which I do not often do), and after having recently switched to a new JDK update so that I was asked to reauthorize. Reopening in case I can somehow use local information to better diagnose what is happening - might be due to a bug in an earlier version of 6.9 used on the same userdir. If the key is in fact corrupt, it may also be possible to delete it so that the warning does not happen again.
Confirmed that most (all?) of my keys beginning with SvnModuleConfig.KEY_CERT_PASSWORD (but not KEY_PASSWORD) are somehow corrupt; when displayed in Seahorse, the value is a read-only blank textfield, rather than the usual read/write textfield (even if I agree to "show the password"). But when I check out a SVN repo I have never encountered before (which does not use client certs), all seems normal - a blank password is stored (blank but read/write textfield in Seahorse) - so I am still guessing that this was a one-time-only problem. Keyring.save has being calling Parameters.notNull since it was first put in the trunk, so storing a null pointer seems unlikely to be the explanation. Can no longer reproduce the warning - unrelated SVN passwords were read that one time, but not when I try again to check out some SVN repo. Still, will try to clean up bad keys after being reported once: core-main #abd234fabc30
Integrated into 'main-golden', will be available in build *201004280200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ User: Log: