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.
NetBeans 7.32 RC2 Windows 7 x64 Oracle Java JDK 7.0.13 x64 Steps executed before the crash: 1) Run application with Project -> Run (to run the web app normally) 2) Debug application with Project -> Debug (to stop tomcat and start again in debug mode) 3) After a while, use choose JSP file and click Run file NetBeans is completely froze (see attached screenshot). Attached is also: - Message log; - VisualVM application snapshot with heap dump and thread dump - Screenshot of the error.
Created attachment 131327 [details] screenshot (still the same after about 30 minutes)
Upload application snapshot (from VisualVM) in Hudson.
Created attachment 131328 [details] messages.log
Please, attach thread dump.
It is on hudson, together with Application snapshot from VisualVM. Regards, Edson
Created attachment 131627 [details] Thread dump after "Run file"... Just to be sure, this is Thread Dump after upgrading NB to DEV (post RC2).
Looking at the thread dump, could this be JSF related?
(In reply to comment #7) > Looking at the thread dump, could this be JSF related? If you mean that page being JSF, no it is not. It is a simple plain JSP page with few <sql:...> and <c:...> standard tags.
Increasing to P1 as per guidelines: http://wiki.netbeans.org/BugPriorityGuidelines
It looks that the deadlock was introduced by fix for issue #222135. ProgressUtils.showProgressDialogAndRun I used for running long-term actions which runs the Runnable in BG (other thread). This thread runs to the parsing lock but since it's already hold due to run action on the file by the first/original thread, it causes deadlock. In other words, it looks to me that all calls into another thread will lead to this kind of deadlock - since it's broken condition of the same thread for the parsing reentrant lock. So no solution w/out the API change likely fix this issue. David if you would agree, I would like to rollback changes for issue #222135 into nb73patch (slowdown is always better than deadlock). Then I would reopen #222135 - everything should be fixed by fixing bug #210214 into the next release. #invokeInBackground() looks irreplaceable here.
(In reply to comment #10) > In other words, it looks to me that all calls into another thread will lead to > this kind of deadlock Looks like that. If that's true though then we never tested it otherwise we would bump into the deadlock earlier. > David if you would agree, I would like to rollback changes for issue #222135 That makes sense. Especially if your consider that issue 222135 is P3 with single slowdown report. > into nb73patch (slowdown is always better than deadlock). Then I would reopen > #222135 - everything should be fixed by fixing bug #210214 into the next I've started working on 210214 for 7.3 but it is a lots of work so I put it on back burner again.
(In reply to comment #11) > (In reply to comment #10) > > In other words, it looks to me that all calls into another thread will lead to > > this kind of deadlock > > Looks like that. If that's true though then we never tested it otherwise we > would bump into the deadlock earlier. Actually it doesn't always lead to the deadlock. During the run must be started/running parsing inside the JSF. To be honest I wasn't able to reproduce that today, but probably I hadn't big project enough. > > David if you would agree, I would like to rollback changes for issue #222135 > > That makes sense. Especially if your consider that issue 222135 is P3 with > single slowdown report. > > > into nb73patch (slowdown is always better than deadlock). Then I would reopen > > #222135 - everything should be fixed by fixing bug #210214 into the next > > I've started working on 210214 for 7.3 but it is a lots of work so I put it on > back burner again. No problem, I understand. I would like just explain that it's short term solution and that there is no other way how to fix that than by the API change which is on the way. :) Thanks for quick answer and your time.
Fixed (backouted) in web-main #0a27b472bea3.
Integrated into 'main-golden', will be available in build *201302270948* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/0a27b472bea3 User: Martin Fousek <marfous@netbeans.org> Log: #226036 - NetBeans frozen on JSP file run, backout of the 2046750f5fc1
For me it works in Dev (Build 201302272300). ecerichter, please verify in your environment.
Yes, I can confirm the problem is not happening any more since 201302272300.
Transplanted: changeset: 255531:ff9beb128041 branch: release73 summary: #226036 - NetBeans frozen on JSP file run, backout of the 2046750f5fc1 changeset: 255532:ded9e5181ee5 branch: release73 summary: Spec.version and long description for #226036
Integrated into 'releases', will be available in build *201303141828* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/ff9beb128041 User: Martin Fousek <marfous@netbeans.org> Log: #226036 - NetBeans frozen on JSP file run, backout of the 2046750f5fc1 (transplanted from 0a27b472bea30250d3c76950720e65323a22f2f8)