Bug 248308

Update:
- The crash happens with jdk 8u20, too.
- It also crashes in the same way with Java 8u20 and 8u25 on another computer, with Windows 7 32 bit edition (and works fine with 8u11)
- Most of the times, it crashes when opening menus of Netbeans

Blocked in classloading.

Jardo, please evaluate.

additional info to reproduce it, it crashes (not only) doing the following:
- crashes when opening "check for updates", "Start page" or "about" in the help menu
- also crashes when using CTRL + Space Auto Complete to browse Java API or foreign library classes

These functions work fine with 8u11, including online update etc.

Somebody opens secure HTTP connection which needs to get access to keyring (and holds some locks), but that blocks all classloading from SystemCL, including thread that is supposed to show the keyring...





        at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
        at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettin
gs.java:230)
        at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthent
icator.java:87)
        at java.net.Authenticator.requestPasswordAuthentication(Authenticator.ja
va:317)
        - locked <0x108daba0> (a org.netbeans.core.NbAuthenticator)
        at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(N
egotiateCallbackHandler.java:65)
        at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(Nego
tiateCallbackHandler.java:86)
        at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginM
odule.java:858)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Kr
b5LoginModule.java:704)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.ja
va:617)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:1
95)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:6
80)
        at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
        at sun.security.jgss.GSSUtil.login(GSSUtil.java:255)
        at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
        at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.ja
va:335)
        at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.ja
va:331)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.j
ava:330)
        at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredent
ial.java:145)
        at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechF
actory.java:122)
        at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFa
ctory.java:187)
        at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.j
ava:224)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:2
12)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:1
79)
        at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoConte
xt.java:852)
        at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.j
ava:317)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:2
48)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:1
79)
        at sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.j
ava:108)
        at sun.net.www.protocol.http.spnego.NegotiatorImpl.<init>(NegotiatorImpl
.java:117)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
        at sun.net.www.protocol.http.Negotiator.getNegotiator(Negotiator.java:63
)
        at sun.net.www.protocol.http.NegotiateAuthentication.isSupportedImpl(Neg
otiateAuthentication.java:130)
        - locked <0x05fb6190> (a java.lang.Class for sun.net.www.protocol.http.N
egotiateAuthentication)
        at sun.net.www.protocol.http.NegotiateAuthentication.isSupported(Negotia
teAuthentication.java:102)
        - locked <0x0f9ee898> (a org.netbeans.ModuleManager$SystemClassLoader)
        at sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHe
ader.java:180)
        at sun.net.www.protocol.http.AuthenticationHeader.<init>(AuthenticationH
eader.java:126)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLCo
nnection.java:1589)






"org.netbeans.api.keyring.Keyring" #39 daemon prio=1 os_prio=-2 tid=0x2d6f6800 n
id=0x126c waiting for monitor entry [0x33e9f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleM
anager.java:690)
        - waiting to lock <0x0f9ee898> (a org.netbeans.ModuleManager$SystemClass
Loader)
        at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390)

I think this is caused by JDK bug 
https://bugs.openjdk.java.net/browse/JDK-8032832
it introduced the additional classloader synchronzation which is causing the issue:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8379313ae50e

+            // Lock on the class loader instance to avoid the deadlock engaging
+            // the lock in "ClassLoader.loadClass(String, boolean)" method.
+            synchronized (loader) {
+                return isSupportedImpl(hci);
+            }

https://bugs.openjdk.java.net/browse/JDK-8068184

*** Bug 249723 has been marked as a duplicate of this bug. ***

*** Bug 250664 has been marked as a duplicate of this bug. ***

The Problem still exists with NetBeans 8.0.2 and Java 8u60. Can someone please upvote the relevant JDK bug? We are forced to use Java 8u11 for NetBeans (we are behind a proxy requiring credentials; this seems to cause access to the key store and the subsequent lock up) as this is the last working Java version. Or is there a workaround we do not know of?

a workaround is to disable network access for Netbeans by setting the connection to "no proxy". Of course all online funtions of Netbeans stop working this way.

Another rather complicated workaround (havn't checked) might be to install a local Proxy Server on the computer running Netbeans, and make this Server talk to the MS Proxy Server. Netbeans could then use the local proxy server without AD authentication.
However, I am still using java 8u11 for Netbeans, too.

Well, no internect connectivity in NetBeans really hinders usability (online help etc.). On a side note: this is (of cource) also an issue for derieved applications like VisualVM but, at least for us, not that painful there (Java 8u11 for updates and plugion installs, and no proxy when monitoring ...). Maybe mentioning this fact in the JDK bug report could press the issue there?

Is there any update on the JDK issue being fixed. we still see it with JDK 8u65

*** Bug 256556 has been marked as a duplicate of this bug. ***

repeated in jre 1.8.u73

I had this bug after updating to JDK8, deinstalling and then installing 1.7.0_80. I was (apparently) able to solve it by 1) deleting a lot in the %temp% directory, and 2) temporarly removing the LAN cable.

Some more about this:
- I'm on windows 7 professional and use netbeans 8.0.2
- didn't happen with 1.7.0_71
- does happen with 1.7.0_80 and 1.8.0_74
- I'm behind a corporate proxy
- setting -J-Dhttps.proxyHost, -J-Dhttp.proxyHost didn't help
- doesn't happen when pulling off LAN cable *before* starting
- doesn't happen if "show start page" is disabled
- it happens again if the start page is enabled after being started without

So from now on I'm working with a disable start page!

This seems to be happening to me as well.
I'm behind a transparent proxy
Netbeans 8.1
1.8.0_92
Ubuntu

Switching to a manual proxy and specifying a username and password fixes this issue for me.

This plugin resolved my issue while being behind a transparent proxy:
http://plugins.netbeans.org/plugin/55258/proxyselector-v2

Hi is there some progress? Can someone contact Anton Litvinov (who has issue assigned in OpenJDK) and enforce him to fix it? This bug is more than 1.5 year old with P1 priority!

I had similar kind of problem. Now its working for me, I cleared Netbeans cache located at "C:\Users\<Your Username>\AppData\Local\NetBeans\Cache" on my Windows machine.

*** Bug 262883 has been marked as a duplicate of this bug. ***

This bug is alive and well causing havoc and time and frustration and disappointment. I have had no problems prior to loading version 8.2. Had 7.2 for years and worked fine, but I thought I needed this version for Vert.x software. Turns out to be the worst nightmare I've ever had. Loaded and reloaded both 8.2 and 7.2 - now neither one works - both just keep locking up, shutting down erratically sometimes immediatly ' smetimes delayed reaction. Always happens and you want me to install automatic updates??? You must be jokin, huh???

As suggested above, it appears there is a solution, not just a workaround here:

https://bitbucket.org/phansson/netbeansproxy2
available via
http://plugins.netbeans.org/plugin/55258/proxyselector-v2

This could become part of the NetBeans implementation not just an optional plugin.

The Proxy Selector v2 Plugin does not help at all, Netbeans still deadlocks with it.
The only workaround that helps is to use a simple local proxy server and make Netbeans talk to this local server. (which than forward all data 1:1 to the real proxy)
It seems the bug in Java which causes this bug isnt going to be fixed, so please reconsider making a workaround in Netbeans!

Hi, Peter here, author of ProxySelector2.

I have some comments, background and maybe a solution.

Background: Problem happens on sites that use a network proxy which uses SPNEGO for authentication.

For many years it used to be that proxies in corporate networks would use NTLM for authentication (hopefully NTLMv2 as NTLMv1 is easily cracked). Java SE works well with a proxy that uses NTLM authentication. Now SPNEGO seems to be the prevailing method for proxy authentication in corporate networks. Unfortunately Java SE on Windows only works in theory against a HTTP endpoint (or intermediary) which uses SPNEGO. You can read more about this on Stackoverflow for the full story:

https://stackoverflow.com/questions/14556119/how-do-people-make-java-spnego-client-work-in-windows

What seems to be happening here is that the SPNEGO authentication fails. This is no surprise given the details in the SO article. When authentication fails then the JRE will invoke whatever Authenticator is registered with the JRE. In this case this is NbAuthenticator. Indeed this Authenticator will try to access NB Keyring.
(side note: I'm no fan of NB's own Authenticator, you can find an alternative one here: https://bitbucket.org/phansson/netbeansnetworkauthenticator, but won't solve this specific problem, though)

The real issue is the JDK bug, I think (which btw isn't properly reported to Oracle, IMO). The JDK bug creates a deadlock with the NbAuthenticator which uses Keyring, which uses Future(s) for read operation. Bam!

However, the question is: What would happen if SPNEGO didn't fail and therefore the JRE wouldn't have to invoke the Authenticator? Clearly this is a workaround to the JDK bug, but I may just work. And then how to make SPNEGO work you ask?  Well, read the Stackoverflow article referenced above. (yes, you'll need to change a windows registry key). This may just work.

Another workaround would be to use an alternative Authenticator (like mine) which doesn't use Keyring or at least allows to disable its usage. (don't get me wrong: my own Authenticator doesn't have this feature at the moment, I'm just saying mine *could* have such a feature)

I hope this rambling helps someone.

Apologies for saying the JDK bug isn't properly reported to Oracle. I missed Antonin's comment above. The correct JDK bug is: https://bugs.openjdk.java.net/browse/JDK-8068184

*** Bug 262883 has been marked as a duplicate of this bug. ***

In my case where the Proxy Selector v2 Plugin does not help, NetBeans still deadlocks with it as reported by others.

If I disable all network activity on startup via changing NetBeans internal configuration files, such as checking for updates, downloading maven index, then testing the network connection in the options dialog freezes the IDE as expected.

The interesting part is that the IDE freezes when I click the test button early enough while projects are being opened. However, if I wait for the opening of projects to complete (definitely), and for scanning complete (not sure if that matters), then the IDE does not freeze. It takes a little while for the test to succeed though.

Perhaps useful for working around this in code by means of some kind of scheduling.

(In reply to bht from comment #28)
> In my case where the Proxy Selector v2 Plugin does not help, NetBeans still
> deadlocks with it as reported by others.
> 
> If I disable all network activity on startup via changing NetBeans internal
> configuration files, such as checking for updates, downloading maven index,
> then testing the network connection in the options dialog freezes the IDE as
> expected.
> 
> The interesting part is that the IDE freezes when I click the test button
> early enough while projects are being opened. However, if I wait for the
> opening of projects to complete (definitely), and for scanning complete (not
> sure if that matters), then the IDE does not freeze. It takes a little while
> for the test to succeed though.
> 
> Perhaps useful for working around this in code by means of some kind of
> scheduling.

Yes, ProxySelector2 doesn't help because the triggering factor is the Authenticator, not the ProxySelector. Even if you use ProxySelector2 you'll still be using NB's own Authenticator.

The problem here is "how to replicate the scenario?" for those of us who can fix the issue. Personally, while I have a test bed with various types of proxies, I do not have one which uses SPNEGO. I cannot emulate with another type of proxy authentication because said JDK issue is only in the JDK class that deals with SPNEGO authentication.

If I can emulate/replicate consistently then I'm also confident that a stable workaround is possible. But we are a bit far from that at the moment. (by stable workaround I mean something that works consistently and that can be explained *why* it works)

Given the popularity of SPNEGO auth on corporate proxies I see this bug as a real problem for the success of the NetBeans Platform / NetBeans IDE. 

@bht: Did you try to implement the aforementioned workaround, windows registry key 'allowtgtsessionkey' ? (if your company policy allows you to)

Hi phansson, I use "Manual Proxy Settings" + "Proxy Requires Explicit Authentication". Does SPNEGO and windows registry key 'allowtgtsessionkey' apply in that case?
It is important to note that I am logged in as admin user which has different credentials from the user in the NB manual proxy configuration. From my perspective, this is a fairly clear cut use case, and it indicates that perhaps we are talking about different scenarios. On a different computer using the same proxy with NetBeans configured "Use System Proxy Settings", Proxy Selector v2 Plugin solves the problem.

All this indicates to me that we need a flow chart where observations from different parties having  different environments can be visualized.

Created attachment 164565 [details]
Toubleshooter flow chart png

Flow chart exported from Toubleshooter.graphml

Created attachment 164566 [details]
Troubleshooter Flow chart file

Editable with yed

(In reply to bht from comment #30)
> Hi phansson, I use "Manual Proxy Settings" + "Proxy Requires Explicit
> Authentication". Does SPNEGO and windows registry key 'allowtgtsessionkey'
> apply in that case?
> It is important to note that I am logged in as admin user which has
> different credentials from the user in the NB manual proxy configuration.
> From my perspective, this is a fairly clear cut use case, and it indicates
> that perhaps we are talking about different scenarios. On a different
> computer using the same proxy with NetBeans configured "Use System Proxy
> Settings", Proxy Selector v2 Plugin solves the problem.
> 
> All this indicates to me that we need a flow chart where observations from
> different parties having  different environments can be visualized.

I would love to claim that ProxySelector2 actually solves something in this case. But I just cannot see how that can be the case. SPNEGO authentication fails resulting in the JRE having to activate the Authenticator (which ProxySelector2 doesn't change from std NB), the Authenticator tries to access Keyring ... and bum : deadlock. As the name implies a ProxySelector doesn't deal with authentication. It deals with which proxy to use for a given URL. That's it. I know a fair amount about proxy setup discovery and runtime proxy selection in Java and in the NetBeans Platform in particular, but proxy authentication is another topic. (I probably shouldn't have ventured into giving advice on the latter :-))

When you see different results on different machines it is most likely due to differences in Windows environment (e.g. what kind of user are you?, what registry keys are set?, etc). Under some scenarios - I believe some local admin scenarios coupled with some UAC - there's no way to get SPNEGO to work with Java SE *even* if you also set the windows registry key 'allowtgtsessionkey'.

Anyway are you saying that on same machine, same windows account, same NB Proxy Setup, etc, then it makes a difference whether you have ProxySelector2 installed or not? 

I appreciate the idea of a troubleshooting flowchart. However, it very quickly becomes very complex as the combinations are endless. The problem is that I for one simply do not know enough about Java SE's proxy authentication abilities to be able to come up with solid recommendations. It also requires a thorough understanding of the given proxy. For example what auth options does the particular proxy offer? Is it SPNEGO with or without fallback to NTLM?  Does it offer Basic too? etc. Typically this can only be revealed using trial-and-error or perhaps using Wireshark to sniff the HTTP traffic.

(In reply to phansson from comment #33)
> Anyway are you saying that on same machine, same windows account, same NB
> Proxy Setup, etc, then it makes a difference whether you have ProxySelector2
> installed or not? 
ProxySelector2 works on a different machine using the same proxy when using NB System Proxy Settings. Different Windows account (matching proxy account) that is why System Proxy Settings is productive. Manual proxy settings with  "Proxy Requires Explicit Authentication" is used on the problem machine only because the Windows account credentials do not match the credentials for the proxy. That is a typical thing to happen. As developers, we have some VMs where we are in fact logging with an admin account, but the network connections through the proxy must use the normal account credentials which are used on the non-development corporate network. Of course it could be as you say that the machines are different and some timing effect works around the deadlock. But that is the point. We need a workaround, and the timing might be the key here.
> 
> I appreciate the idea of a troubleshooting flowchart. However, it very
> quickly becomes very complex as the combinations are endless.

Perhaps. But recording the complexities is the point of it, record the combinations in it and use it as a analysis and discovery tool.

> The problem is
> that I for one simply do not know enough about Java SE's proxy
> authentication abilities to be able to come up with solid recommendations.
> It also requires a thorough understanding of the given proxy. For example
> what auth options does the particular proxy offer? Is it SPNEGO with or
> without fallback to NTLM?  Does it offer Basic too? etc. Typically this can
> only be revealed using trial-and-error or perhaps using Wireshark to sniff
> the HTTP traffic.

I think that we don't all need to be experts in everything to help find a better solution. Just pooling ideas is much appreciated and might help. This is opened in 2014, and mission critical, P1, I don't really care how the solution is generated, but something needs to happen.

Running NB 8.2 on Windows 7, 64-bit, with proxy server.  Tried setting to manual and automatic, with no difference.
NetBeans often (but not always) freezes during "Opening Projects" the first time I attempt to launch the IDE after a restart of the PC. After forcing the application to close using Windows Task Manager I am usually able to start it.  Today I have tried three times and it is still frozen.

Potential issue or workaround:
After several unsuccessful attempts to start NetBeans (and be able to get paid for doing work), I decided to uninstall and reinstall version 8.2.  The uninstall process was halted with an errors that there was a lock file that had to be removed.  
So, on a hunch, I removed the file (c:\users\<username>\AppData\Roaming\NetBeans\8.2\lock)
As soon as I removed the file, Windows states the uninstall may not have been successful (no uninstall occurred).
I launched NetBeans again and it finally came up, this time prompting me for my LAN password.

I hope this will help others and especially those fixing this annoying glitch.

I've been able to successfully replicate this bug.

As expected it requires the presence of a network proxy which uses the 'Negotiate' method for silent authentication. (as stated, this is actually what the majority of corporate intranets do these days).

I've set up a Squid proxy that uses Negotiate for authentication. I then made sure that the silent auth mechanism would fail. There are possibly multiple ways to do that. Even if your proxy works for Chrome, IE, Firefox, etc, it will likely still fail for use from within a Java SE application such a NetBeans. (the reason is here: https://stackoverflow.com/questions/14556119/how-do-people-make-java-spnego-client-work-in-windows, but that's not the problem we're here to solve)

Anyway, with my Squid proxy testbed the bug is very visible. NetBeans will lock up. It is also clear that it is because of the reason stated in comment 5. (not that I ever doubted it)

I've tried a few workarounds with my own Authenticator class. Ultimately no attempt of mine has worked. This shouldn't be a surprise. Solving it in the authenticator class is simply too late. The lock on the classloader is already there at that point.

I'm at a loss of solving this problem without Oracle stepping in and reverting what they did in JDK-8032832, as requested in JDK-8068184. There's little chance that will happen so I hope someone can come up with ideas for workaround. 

Bottom line:  The standard Java HTTP Client (known as HttpURLConnection) is holding a lock on the classloader at the time when it calls upon the Authenticator to get credentials. I haven't been successful in designing an Authenticator that wouldn't somehow need classloading and thus be blocked. 

HELP! Good ideas are welcome.

Some good products are shipped with their own JRE. Very common. So why not ship a clean JRE (new patched or old without the JDK bug) with NetBeans?

As jdk9+181 is regarded as the jdk9 release candidate (http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-August/005940.html) - did anyone test if this bug still applies to netbeans-dev under jdk9? I can't test this as I have no access to windows machines any more.

(In reply to rkraneis from comment #39)
> As jdk9+181 is regarded as the jdk9 release candidate
> (http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-August/005940.html) -
> did anyone test if this bug still applies to netbeans-dev under jdk9? I
> can't test this as I have no access to windows machines any more.

Just for reference: The bug is not related to any particular OS per se, but it will manifest itself more often on this OS as there's a greater chance on Windows that Java cannot get a Kerberos Ticket from the OS.

Anyway, I'll test on JDK9 but I'm not optimistic as I can find no evidence that something has changed in JDK9 in this respect.

Have a look in JDK9 Mercurial:
\src\java.base\share\classes\sun\net\www\protocol\http\NegotiateAuthentication.java

and you'll see that it is exactly the same.

(In reply to bht from comment #28)
> If I disable all network activity on startup via changing NetBeans internal
> configuration files, such as checking for updates, downloading maven index,
> then testing the network connection in the options dialog freezes the IDE as
> expected.
> 
> The interesting part is that the IDE freezes when I click the test button
> early enough while projects are being opened. However, if I wait for the
> opening of projects to complete (definitely), and for scanning complete (not
> sure if that matters), then the IDE does not freeze. It takes a little while
> for the test to succeed though.
> 
> Perhaps useful for working around this in code by means of some kind of
> scheduling.
While options to solve this appear to be running out, perhaps worth consideration?
It appears that under some conditions this bug even if present can be worked around so that could be the key for a solution. 

(In reply to phansson from comment #37)
Since you can reproduce this bug with a proxy, apparently we are now in a better position to test this idea.

I've created a minimalistic dummy proxy server (literally 10 lines of code) which will show off the bug for anyone not having access to a corporate style network proxy.

https://bitbucket.org/phansson/dummy-proxy-server

Just run it on your workstation. Change your proxy settings to use localhost:3128 and bam!  ... NetBeans IDE will freeze. Instructions in the README.

I found similar problems reported in the bug trackers for Eclipse and IntelliJ IDEA:



https://bugs.eclipse.org/bugs/show_bug.cgi?id=469116

https://youtrack.jetbrains.com/issue/IDEA-133187



I've also asked for advice on the JDK Securiy Dev mailing list:

http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016267.html

I've now come up with a workaround to JDK-8068184 which means that NB won't freeze anymore. The downside is that the network connection which is triggering the (potential) deadlock, will be aborted.  But at least NB won't freeze. 

User will be alerted to the situation via NB's Balloon Notification mechanism. Screenshots are here: https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround

If you want to use this then you need to install plugin "Network Authenticator" from the Plugin Portal. A prerequisite is plugin "ProxySelector V2" so you need that one installed too.

The "Network Authenticator" plugin btw also contains many improvements over and above NB's own equivalent. In particular in how it presents itself to the user. 

If your NB really freezes every time you start it - not at all unlikely - then I realize it will be difficult for you to even get to the point where you can install said plugins and thus fix the problem. You'll need a way to tell NB - at least temporarily - that you do not want to use a proxy. Here's a potential solution to that: (1) start by manually downloading said plugins to your harddrive, (2) turn off all use of network proxies in Windows' Internet Settings, (3) start NB and install the two plugins, (4) exit NB, reset what you did in step 2, and (5) start NB again and hopefully enjoy the bliss.

I have run into this issue, using latest download from NB, IDE 8.2.  Symptom is that, after a while of using, UI freezes.  Window frame is there, but nothing else inside.

My only way to get around it is to uninstall the IDE, and install it again.  Does anyone know of a simpler way?  I do see the option of using a proxy above.

I tried removing the cache, to no avail.

Created attachment 165108 [details]
jstack thread dump after freeze.  See farokh.morshed comment.

jstack thread dump after freeze.  Freezes when I launch NB 8.2, from inside Oracle network.

(In reply to fmorshed from comment #46)
> Created attachment 165108 [details]
> jstack thread dump after freeze.  See farokh.morshed comment.
> 
> jstack thread dump after freeze.  Freezes when I launch NB 8.2, from inside
> Oracle network.

Judging from your thread dump it doesn't seem to be related to the issue in this ticket. In fact I don't understand from the thread dump why it is frozen at all. In any case the Ctrl-Break method of obtaining a thread dump from a Java application is highly favored over the jstack method. The former gives so much more info. Please attach new thread dump.

Ctrl-Break method: Start NetBeans from a console so that it leaves a console window open in the background. On Windows you can simply start it from cmd.exe. Wait for the IDE to freeze and then press Ctrl-Break on the console window. (if you are on Unix/Linux you would do 'kill -3 <pid>'). The thread dump will come in the console window. Copy that to a file and attach here.

Created attachment 165111 [details]
ctrl-break thread dump for the comment by farokh.morshed

ctrl-break thread dump for the comment by farokh.morshed

(In reply to fmorshed from comment #48)
> Created attachment 165111 [details]
> ctrl-break thread dump for the comment by farokh.morshed
> 
> ctrl-break thread dump for the comment by farokh.morshed

Hi fmorshed

I've looked at your latest thread dump and it is for sure not related to the issue in this ticket. Please log a new ticket and include the Crtl-Break thread dump and any other observations you may have.

I have asked someone from NB team to take a look at this bug report.  They are in the process of doing that.  Until they have a look and make comments, let's keep it all together.

Thanks.

farokh

@fmorshed


This bug in this ticket is characterized by the fact that you'll always be able to find the following in your thread dump:

   at sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:<lineno>)
        - locked <<objectid>> (a org.netbeans.ModuleManager$SystemClassLoader)


You are affected if you are on a site which uses a network proxy which uses the 'Negotiate' scheme for authentication (aka SPNEGO). This is typically found in sites that base themselves on Microsoft stack.

Your problem is something else. Your scenario doesn't fit any of this.

I removed my NB's user directory and NB came up successfully.  This issue is tracked here:  https://forums.netbeans.org/ptopic67458.html.

So, in my case, see my comments above, I could sometimes be hitting the issue tracked here, or the issue tracked in above bug report!  

By the way, immediately after installing NB, this time, I said "no proxy" in the preferences.  Not sure, if this is a workaround for the issue tracked here or not.

Both of these issues are very important.  I will continue to push these with NB's team.

has been logged now also in Apache NetBeans : https://issues.apache.org/jira/browse/NETBEANS-58.

I'll create a pull request with a fix to the core at Apache NetBeans (once the project is ready to accept pull requests).  Once this goes into the core you'll no longer need the fixes described in comment 44.

*** Bug 256713 has been marked as a duplicate of this bug. ***

Those who build their own app based on nb platform and control how it will be packaged can turn off proxy by adding proxyType=0 into userdir\config\Preferences\org\netbeans\core.properties
This way nb first starts with no proxy and then user can fill in real user and password explicitly

very good post.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com