[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053551#comment-17053551
]
Isaac edited comment on NETBEANS-58 at 3/6/20, 4:23 PM:
The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184]
has now closed with a fix version of Java 14. The fix is going to be backported
to Java 7, 8 and 11. Let's see if the fix works.
was (Author: isaac):
The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184]
has now closed with a fix version of Java 14. The fix is going to be backported
to Java 8. Let's see if the fix works.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053551#comment-17053551
]
Isaac edited comment on NETBEANS-58 at 3/6/20, 4:22 PM:
The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184]
has now closed with a fix version of Java 14. The fix is going to be backported
to Java 8. Let's see if the fix works.
was (Author: isaac):
The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184]
has now closed with a fix version of Java 14. The fix has also been backported
to Java 8. Can those experiencing the issue update to a fixed version of JRE
and try again?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:36 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:35 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:23 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed I have a module within the studio (RCP) able to perform REST call
(trigger by user click), and I am behind a corporate transparent proxy (with
Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857594#comment-16857594
]
jmborer edited comment on NETBEANS-58 at 6/6/19 12:27 PM:
--
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy in NB is often more closed than open.
IMHO this over protects NB "internals" a little too much. I would have
preferred a policy based on greater openness and trust. This would have
greatly facilitate my life.
was (Author: jmborer):
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy is NB is more often closed than public.
IMHO this over protect NB "internals" a little too much. I would have preferred
a policy based on greater openness and trust. This would have greatly
facilitate my life.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3.
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857508#comment-16857508
]
jmborer edited comment on NETBEANS-58 at 6/6/19 10:54 AM:
--
Not sure to understand how the PR is solving the issue. First, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
was (Author: jmborer):
Not sure to understand how the PR is solving the issue. Fist, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857437#comment-16857437
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:48 AM:
-
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
When you navigate the start page it triggers as well GET to
http://netbeans.org/demos.xml
was (Author: jmborer):
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:40 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [ http://netbeans-vm.apache.org/uc/11.0/updates.xml.gz?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a_90e7342f-955b-4cc6-8e15-39e4810b37c2|http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz] Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0, 11.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, > image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt > > > When any network operation is performed, such as attempting to contact > NetBeans Update Center, the application (IDE or Platform) may freeze. Users > will typically experience this on startup. It was reported in old bug tracker > as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308]. > The problem arises because of the fix JDK folks applied as a consequence of > the reported [JDK-8032832 > bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very > clever IMO: it puts a lock on the classloader, thus introducing a range of > other problems, one of them being that NetNeans IDE or NetBeans Platform will > likely freeze on startup when it attempts a network operation. The fact that > their fix made things worse (while no doubt fixing the original issue) has > been reported as > [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184]. > h3. WHEN DOES IT HAPPEN? > As the lock is introduced for authentication of type 'Negotiate' it of course > only happens if there's a network proxy on the path which uses this type of > authentication. Also known as SPNEGO. This form of authentication is in my > experience very common in corporate networks, in particular those that base > themselves on the Microsoft stack. But a person on Oracle's own internal > network, such as a JDK developer, is most likely not exposed to it. :-) > There's another condition for it to happen: The JRE runtime must be unable to > provide 'credentials' (a Kerberos token) to the network proxy on its own. > SPNEGO is really
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:38 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: http://www.netbeans.org/news.xml [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0, 11.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, > image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt > > > When any network operation is performed, such as attempting to contact > NetBeans Update Center, the application (IDE or Platform) may freeze. Users > will typically experience this on startup. It was reported in old bug tracker > as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308]. > The problem arises because of the fix JDK folks applied as a consequence of > the reported [JDK-8032832 > bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very > clever IMO: it puts a lock on the classloader, thus introducing a range of > other problems, one of them being that NetNeans IDE or NetBeans Platform will > likely freeze on startup when it attempts a network operation. The fact that > their fix made things worse (while no doubt fixing the original issue) has > been reported as > [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184]. > h3. WHEN DOES IT HAPPEN? > As the lock is introduced for authentication of type 'Negotiate' it of course > only happens if there's a network proxy on the path which uses this type of > authentication. Also known as SPNEGO. This form of authentication is in my > experience very common in corporate networks, in particular those that base > themselves on the Microsoft stack. But a person on Oracle's own internal > network, such as a JDK developer, is most likely not exposed to it. :-) > There's another condition for it to happen: The JRE runtime must be unable to > provide 'credentials' (a Kerberos token) to the network proxy on its own. > SPNEGO is really designed to be seamless and promptless. Support for it was > added in Java 6. But later on Microsoft tightened the desktop security around > obtaining the so-called 'session token' and the JDK folks were never able to > work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in > real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be > forced to ask the user for credentials, thus negating the idea of SPNEGO. It > is the prompting which causes the freeze.
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857412#comment-16857412
]
Geertjan Wielenga edited comment on NETBEANS-58 at 6/6/19 8:20 AM:
---
So, if there was a switch to cause the Welcome screen not to be shown at
startup or the module providing the Welcome screen to be disabled at startup,
that would solve this?
was (Author: geertjanwielenga):
So, if there was a switch to cause the Welcome screen not to be shown or the
module providing the Welcome screen to be disabled, that would solve this?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader.
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:11 AM:
-
I confirm that this still happens with NB 11.
As I said before, not the best advertisement for NB when you try to convince
people to adopt it.
When you install NB, it will by default open the welcome "start" page which
triggers network requests.
was (Author: jmborer):
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 7:58 AM:
-
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
was (Author: jmborer):
I confirme that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451670#comment-16451670
]
lbruun edited comment on NETBEANS-58 at 4/26/18 5:24 AM:
-
Geertjan Wielenga wrote:
{quote}It is super critical in a specific subset of scenarios, I for one have
never (working within and without a corporate proxy) have never encountered it,
as far as I am aware. Has this problem always been in NetBeans and is the only
solution "to implement more fine grained classloaders"
{quote}
At least two questions there:
# *Why you've never encountered it?* In my experience sites that deploy a
proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use
AD as the base of everything. Is that really where you've been? Also you have
to use a Windows workstation for the problem to occur (due to Oracle's
historical resistance to implement native support for SSPI on Windows ... it is
a long story, but in essence in means that the Kerberos implementation in Java
SE for Windows is extremely crippled when used in desktop scenarios : Java on
Windows cannot automatically obtain a Kerberos ticket which means it is forced
to invoke the Authenticator. On Mac OS X and Linux this would all be seamless,
no need to invoke the Authenticator and therefore no deadlock).
# *Has the problem always existed?* No, not always. The problem was introduced
as a consequence of a [JDK bug
fix|https://bugs.openjdk.java.net/browse/JDK-8032832] which was first
introduced in Java 8u25 and later backported. This fix works fine for the JDK
itself because their classloaders use the [Java 7 (and onwards) new
functionality for
classloaders|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html].
The NB Platform doesn't. The JDK folks phrase it like this: "Synchronization
in the {{ClassLoader}} class was previously heavy-handed, or in technical
terms, _not sufficiently granular_. A request to load a class synchronized on
the entire {{ClassLoader}} object, which made it prone to deadlock.". That is
exactly the problem in the NB Platform's classloaders. (discussed in
NETBEANS-106).
In summary: There are a number of conditions that must exist for the freeze bug
to surface for a user:
# The site uses a proxy which uses Negotiate/Kerberos for authentication. As
this method was largely 'invented' by Microsoft and later standardized as an
RFC, you see this very often on MS centric sites. (it is essentially the same
as what Microsoft cleverly refers to as "Windows Integrated Authentication",
clever because it leads people to be believe that this form of seamless
authentication is only possible on Windows)
# Workstation is Windows (not Mac OS X, not Linux) *
# Lastly, if the Platform or IDE user experiences the bug "without having
touched anything" (which is quite likely) then it is because the Platform
automatically picks up the proxy from the OS/InternetExplorer settings. Hence
users will just experience that the Platform app or IDE hangs the first time
they ever try to use it. Ouch!
Honestly, I think one of the reasons why the problem gets little traction is
because both JDK developers and NB developers have removed themselves somewhat
from parts of their user base by using Mac OS X or Linux as their desktop as
opposed to Windows. I'm partly guilty myself :P
*) I suppose theoretically it can happen on Mac OS X and Linux too if you have
a defunct Kerberos configuration. It is just that on Windows the Java/Kerberos
stack is by default "defunct" (as explained)
was (Author: lbruun):
Geertjan Wielenga wrote:
{quote}It is super critical in a specific subset of scenarios, I for one have
never (working within and without a corporate proxy) have never encountered it,
as far as I am aware. Has this problem always been in NetBeans and is the only
solution "to implement more fine grained classloaders"
{quote}
At least two questions there:
# *Why you've never encountered it?* In my experience sites that deploy a
proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use
AD as the base of everything. Is that really where you've been? Also you have
to use a Windows workstation for the problem to occur (due to Oracle's
historical resistance to implement native support for SSPI on Windows ... it is
a long story, but in essence in means that the Kerberos implementation in Java
SE for Windows is extremely crippled when used in desktop scenarios : Java on
Windows cannot automatically obtain a Kerberos ticket which means it is forced
to invoke the Authenticator. On Mac OS X and Linux this would all be seamless,
no need to invoke the Authenticator and therefore no deadlock).
# *Has the problem always existed?* No, not always. The problem was introduced
as a consequence of a [JDK bug
fix|https://bugs.openjdk.java.net/browse/JDK-8032832] which was
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451798#comment-16451798
]
Geertjan Wielenga edited comment on NETBEANS-58 at 4/25/18 7:41 AM:
[~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and
Netbeans Authenticator with the NB platform!!"
OK, is this the following, by [~phansson], or are you referring to something
different?
[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
[https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround]
Also note that YOU are the NetBeans team, too. :) I.e., please do provide a PR
or state what you are specifically asking for here.
was (Author: geertjanwielenga):
[~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and
Netbeans Authenticator with the NB platform!!"
OK, is this the following, by [~phansson], or are you referring to something
different?
[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
[https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround]
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:24 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:05 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:35 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:33 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:27 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:26 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:18 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:16 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
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:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.java:108)
at
sun.net.www.protocol.http.spnego.NegotiatorImpl.(NegotiatorImpl.java:117)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:08 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2
tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708)
- waiting to lock <0xc0d64370> (a
org.netbeans.ModuleManager$SystemClassLoader)
at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390)
at
org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135)
at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483)
at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390)
at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673)
at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509)
at org.openide.util.Lookup.lookupAll(Lookup.java:312)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:05 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#FF}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#FF}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock on
{color:#FF}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{code:java}
"org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2
tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708)
- waiting to lock <0xc0d64370> (a
org.netbeans.ModuleManager$SystemClassLoader)
at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390)
at
org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135)
at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483)
at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390)
at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673)
at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509)
at org.openide.util.Lookup.lookupAll(Lookup.java:312)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:11 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend and advertise the usage of NB in
your company when it just blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically it makes NB IDE unusable. People will drop NB in favor for other
(more reliable) IDE's which is pity and not to speak about the NB platform
applications... It is hard to defend NB in your company when it just blocks
right after startup...
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}},
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator,
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449497#comment-16449497
]
Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:05 AM:
-
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171
on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned.
was (Author: mcrender):
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171
on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449497#comment-16449497
]
Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:05 AM:
-
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171
on a Windows 10 OS behind a corporate proxy as Jean-Marc Borer mentioned.
was (Author: mcrender):
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171
on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449497#comment-16449497
]
Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:04 AM:
-
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171
on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned.
was (Author: mcrender):
I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171
on a Windows 10 OS behind a corporate proxy.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem.
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434018#comment-16434018
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/11/18 2:44 PM:
--
I am not the man either for all this classloading stuff. :P
was (Author: jmborer):
I am not the man either for all this classloading fuss.:P
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3.
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432425#comment-16432425
]
Geertjan Wielenga edited comment on NETBEANS-58 at 4/10/18 3:08 PM:
Can you reproduce with earlier/later JDKs, with JDK 9, 10? Can you reproduce
it with Apache NetBeans (i.e., instead of 8.2)?
was (Author: geertjanwielenga):
Can you reproduce with earlier/later JDKs, with JDK 9, 10?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431984#comment-16431984
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 11:24 AM:
---
My comment is a backport of this bugzilla entry which is still true and
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not
absolutely sure, since we often had trouble with the corporate proxy and I
first thought it was my IT team that messed it up again and I had the network
proxy disabled. My trouble started when I wanted to check for IDE updates and
turned the proxy settings on again.
was (Author: jmborer):
My comment is a backport of this bugzilla entry which is still true and
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not
absolutely sure, since I we often had trouble with the corporate proxy and I
first thought it was my IT team that messed it up again and I had the network
proxy disabled. My trouble started when I wanted to check for IDE updates and
turned the proxy settings on again.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt,
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431958#comment-16431958 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 9:14 AM: -- We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. Workaround #1 doesn't work. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ was (Author: jmborer): We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, > netbeans.txt > > > When any network operation is performed, such as attempting to
