This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 160438 [details] log files in zip file Dev (Build 201607090002), Windows Server 2008 R2 Looks like a firewall issue, but this could perhaps be handled. More details are in the attached log file. BTW JVisualVM seems to have a similar problem. It hangs on 'Computing description..."
Created attachment 162054 [details] another messages.log file
This is an "Reproducible, unavoidable crash or deadlock". According to BugPriorityGuidelines at http://wiki.netbeans.org/BugPriorityGuidelines, this must be a P1. I opened it as P1 and now it changed to P2 and I am changing it back to P1 again. I cannot start the IDE. If I want to change the proxy settings, then I cannot do it because I cannot open the menu. If I want to edit the configuration file outside, that does not help because the proxy setting need a password which is not editable in clear text apparently. I am really angry because on every NetBeans release so far for over 10 years, I have found a major issue so severe that I had to conclude that the IDE is not fit as a development tool for a team where the team members are not necessarily biased advocates of the IDE as I am. It is a shame. If in fact there is something wrong with my computing environment then I would like to know it, and in this case the IDE should detect this. In that unlikely scenario, I would surely escalate that that as well. In 2016, a scenario like this is no longer acceptable under any conditions.
I get sometimes similar errors in the log about autoupdate having problems accessing updates. But it's nothing fatal for me, the IDE continues normally. Can you please provide some thread dump? Nothing in the zipped logs indicate a crash or a deadlock of the IDE.
Created attachment 162078 [details] thread dump It is difficult to get thread dumps because it appears that JVisualVM is somehow not able to do it. However, here is one that I was able to take (old, not now).
Thanks for the thread dump. It describes the problem. But it seems to be out of scope for NetBeans :-( The problem is, that sun.net.www.protocol.http.NegotiateAuthentication invokes isSupportedImpl() method under a lock on the context class loader. What is inside that call is insane, because it waits for the Kerberos authentication. And the lock on the class loader blocks Class.forName() call in AWT-EventQueue-0
It does not seem to be a complete deadlock, it just blocks till the network communication finishes. Does it recover after you wait for some time?
No, it does not recover as far as I remember. Please what is the scope if I may ask. I am using a recent JDK 1.8.0_92.
Why can't this run in the background?
Fortunately, there is already a JDK bug submitted for this problem: http://bugs.java.com/view_bug.do?bug_id=8068184 It's caused by a problem in JDK sources and we need to wait for a fix there... You can vote for that JDK bug... *** This bug has been marked as a duplicate of bug 248308 ***
It runs in a background, but the background thread blocks AWT through the lock on the class loader. It's in JDK since JDK 8u25. See also issue #248308.
I think it is difficult to accept to not to have an IDE because of a JDK bug. The IDE should then provide a workaround even perhaps by providing its own replacement classes. I cannot see in the duplicate bug record that there is a definite workaround that is recommended by the NetBeans developers. I tried the plugin http://plugins.netbeans.org/plugin/55258/proxyselector-v2, because I read this duplicate bug before, but that did not work. I cannot unplug the network cable because I am working on a VM and the network is required for services. What I am somehow trying to communicate is that one could reasonably expect that a runtime system such the JRE which is so critical for the functioning of this software and so many others cannot have such a bug without a way out. It is crazy. This is shoddy software then.
What does this mean: "No, it does not recover as far as I remember."
I have had the IDE running over the weekend with this deadlock. No recovery. The IDE does not respond to any user actions - it is still frozen. Then I tried to take a thread dump using JVisualVM. As I wrote before, JVisualVM is impacted by this in some way. It displays "Opening [threaddump] 9:47:31 AM..." and does not return from that. The JVisualVM GUI is still responsive though at this time. Then I tried JConsole, but JConsole cannot see the NetBeans process.
This means you are never able to open NetBeans at all, never? I.e., you have never seen what NetBeans looks like because you can't start it up? Just trying to understand what's going on. Maybe to help identify the problem, can you switch off firewalls or as many other processes as possible, to limit the possible causes of the problem?
(In reply to Geertjan Wielenga from comment #14) > This means you are never able to open NetBeans at all, never? I.e., you have > never seen what NetBeans looks like because you can't start it up? > > Just trying to understand what's going on. > > Maybe to help identify the problem, can you switch off firewalls or as many > other processes as possible, to limit the possible causes of the problem? Thanks Geertjan. This describes the symptoms fairly well. However I was able to start a previous IDE version with a previous JDK. We could in fact try to work around this issue, as users in bug 248308 have done. IMHO those suggestions are voodoo science. Apparently we know the root cause, and I would leave the solution to the competent NetBeans developers. I am only a NetBeans user / advocate, and I am troubled by this not so much because I can't use NetBeans but because I cannot ask anyone else to even try to use it. I know how to get out of this, but I try not to be a hacker (at least not in public). So for now, my copy of NetBeans is locked up. My environment is for now available to the NetBeans developers, so please if it helps, ask me to use this environment in a way that suits you. That is why I am not touching anything for now. Something else that concerns me is bug 262231. It would be good to intensify efforts around this as well to remove the blind spot that comes from not being able to report bugs behind a firewall.
Can you specify what this means: "a previous IDE version with a previous JDK"? What does 'voodoo science' mean in this context? You 'know how to get out of this'. What does that mean? Can you explain how to get out of this? 'My environment is for now available to the NetBeans developers' -- what does that mean, where is that environment that you're talking about? It is difficult to help you -- can you provide details so we can replicate the problem so that we can solve it?
(In reply to Geertjan Wielenga from comment #16) > Can you specify what this means: "a previous IDE version with a previous > JDK"? Say NetBens 7.4 or current NetBeans with JDK 1.7 > > What does 'voodoo science' mean in this context? It means that someone makes a change to the system in a way and the next day the IDE works. Then he concludes that the change actually fixed the problem, where in fact the time interval for the auto update just passed, and the system would have worked fine without the change. I would classify some suggestions for solutions in bug 262231 in that category. > > You 'know how to get out of this'. What does that mean? Can you explain how > to get out of this? By that I mean to do some unorthodox changes to the NetBeans internal files which I would not want to recommend. > > 'My environment is for now available to the NetBeans developers' -- what > does that mean, where is that environment that you're talking about? I am working on multiple virtual Windows computers, one of which runs the frozen NetBeans instance. I would leave the running instance untouched and would do whatever the NetBeans developers suggest. Normally I could not do that because I would have to keep working remove the evidence so to speak. > > It is difficult to help you -- can you provide details so we can replicate > the problem so that we can solve it? The problem has already been replicated. The root cause has been identified. What details do you need?
What are the "unorthodox changes to the NetBeans internal files which I would not want to recommend"?
Created attachment 162206 [details] IDE frozen with JVisualVM when trying to download maven index This seems to be a wider issue. As can be seen in this screenshot, JVisualVM cannot see NetBeans. This happens when NetBeans gets past the autoupdate which is disabled. The IDE just takes the next possible opportunity to lock up.
Created attachment 162207 [details] messages.log to match the latest scenario
Created attachment 162210 [details] Thread dump for the latest scenario When I disable the the maven index download via the Index Update Frequency setting, then there is an issue with the test connection button of the proxy settings as follows: The test does not finish with a failure even when I wait. The Cancel button on the dialog just hides the dialog, and when I open the Options dialog later, then it is still in its previous state, on the connection test with the progress bar animated. In the above case, the IDE is again frozen to the degree that I cannot close it, I cannot interact with the menu, anything. JVisualVM waits indefinitely trying to connect to NetBeans which is now shown in it. JVisualVM finally allowed me to take a thread dump, but its progress bar is still showing "Opening NetBeans ...", being animated. Could you please try to make an improvement to the NetBeans networking code in general. F feel that anything could help. I think that I have demonstrated that the code is lacking robustness. As I have suggested elsewhere in this system, it would help to apply a strategy of post mortem analysis. The user needs feedback regarding the the source of the problem. A contemporary computer program should be able to sort out these type of issues without the requirement for support action.
It appears there is a solution, not just a workaround here: https://bitbucket.org/phansson/netbeansproxy2 available via http://plugins.netbeans.org/plugin/55258/proxyselector-v2 This could become part of the NetBeans implementation not just an optional plugin.
We started running into this issue this week. No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. 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"... I wote for a P1 issue!!
Created attachment 163507 [details] Frozen stack trace with Java x64 8_121 and Netbeans 8.2 Win7x64
(In reply to bht from comment #19) > Created attachment 162206 [details] > IDE frozen with JVisualVM when trying to download maven index > > This seems to be a wider issue. As can be seen in this screenshot, JVisualVM > cannot see NetBeans. This happens when NetBeans gets past the autoupdate > which is disabled. The IDE just takes the next possible opportunity to lock > up. I had exactly the same behavior: once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisVM 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. No really astonishing since it based on NB platform.
Created attachment 163508 [details] Another frozen stack trace with Java x64 8_121 and Netbeans 8.2 Win7x64 Look for lock 0x00000000c0d64370. There is the issue.
After further analysis of my second thread one can see that the issue lies in: 1) "Thread-8" takes the lock 0x00000000c0d64370 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 0x00000000c0d64370. Boom deadlock... This blocks the lock on 0x00000000c0d64370 for every other thread including the AWT Event one.
The suggested ProxySelector solution does not resolve the issues in all scenarios. Please read NetBeans Proxy Troubleshooting https://bitbucket.org/phansson/netbeansproxy2/issues/2/netbeans-proxy-troubleshooting
The Proxy Selector v2 Plugin does not help, Netbeans still deadlocks with it. The only workaround that helps me is to use a simple local proxy server and make Netbeans talk to this local server. (which than forward all data 1:1 to the real proxy) This seems to be the same bug as 248308 and 256713, unfixed since 2014. It seems the bug in Java which causes this bug isnt going to be fixed, so please reconsider making a workaround in Netbeans! Makes me wonder if Netbeans is really a supported development platform...
Yeah I experienced exactly the same. I think I spotted the place in the plugin were it could be fixed(hacked), but I didn't had time to investigate further. Difficult to reproduce elsewhere as at the working place and I need to start the IDE in debugging mode. I had to use cntlm to solve my issue so I stopped my investigations to fix ProxySelector. Sorry.
As far as I remember the solution would be not to trigger the retrieval of the Keyring on another thread. I considered hacking the NB code to avoid this call in org.netbeans.api.keyring.Keyring. Please NB team fix the issue by not posting the retrieval on another thread!!
I have an interesting detail from my case where the Proxy Selector v2 Plugin does not help, Netbeans still deadlocks with it as reported by others. If I disable all network activity on startup via changing NetBeans internal configuration files, such as checking for updates, downloading maven index, then testing the network connection in the options dialog freezes the IDE as expected. The interesting part is that the IDE freezes when I click the test button early enough while projects are being opened. However, if I wait for the opening of projects to complete (definitely), and for scanning complete (not sure if that matters), then the IDE does not freeze. It takes a little while for the test to succeed though.
*** This bug has been marked as a duplicate of bug 248308 ***
(In reply to bht from comment #32) > I have an interesting detail from my case where the Proxy Selector v2 Plugin > does not help, Netbeans still deadlocks with it as reported by others. > > If I disable all network activity on startup via changing NetBeans internal > configuration files, such as checking for updates, downloading maven index, > then testing the network connection in the options dialog freezes the IDE as > expected. > > The interesting part is that the IDE freezes when I click the test button > early enough while projects are being opened. However, if I wait for the > opening of projects to complete (definitely), and for scanning complete (not > sure if that matters), then the IDE does not freeze. It takes a little while > for the test to succeed though. Yes, as seen from the comments on #248308 the root cause is a lock on the classloader. Hence the problem occurs on startup. If you wait long enough and there's no longer any contention, then it is not strange that you won't see the problem.
Created attachment 164564 [details] Troubleshooting flow chart png Flow chart exported from Toubleshooter.graphml