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.
Set browser to Swing Browser. Put breakpoint to JSP. Start debugger. IDE hangs.
Created attachment 16317 [details] Thread dump
You don't have to put breakpoint to JSP, IDE will hang anyway. Same for debugging servlets. Running JSP or Servlet works without hang.
We had a workaround for debugging in org.openide.awt.SwingBrowserImpl. Look for org.openide.awt.SwingBrowserImpl.do-not-block-awt property here and check if debugger sets it.
Cool, thanks for help Radime. Debugger does not set the property - there used to be this code in DelegatingDebugger in 36: System.setProperty("org.openide.awt.SwingBrowserImpl.do-not-block-awt", String.valueOf(state != DEBUGGER_NOT_RUNNING)); but there's no such code in 4.0 - ressigning to dbgjpda - please set the property when debugger running.
It must be some mistake. Debugger does not use Swing Browser. Feel free to set this property if your module runs Swing Browser inside the debugger.
What about if user does attach to some server and uses swing browser to reach some page? What then? I believe this must be set for all dbg sessions.
I do not understand this request. Looks like some patching of Swing Browser functionality. But Patches for SwingBrowser should be in module providing SwingBrowser. Moving SwingBrowser patches to debugger code is not a good practise...
we can't do it from inside SwingBrowserImpl. This is a special case for debugger. Truely we should have an official API for that but it's not and we're after feature freeze. Either the JSP debbuger or the JDPA debugger will have to initiate the special case, using this hack at least for D. Tim has already at least once suggested to kill SwingBrowser entirely. It doesn't really live up to what the user expects from a web browser anyway
Looks like architecture problem in web module. 1) Do not open SwingBrowser if it does not work, or open it externally - not inside the NetBeans JVM. 2) If you sill needs do it internally - provide patch in your code for debugging. 3) If its not possible to implement patch in your code, feel free to suggest patch to some other module.
I don't understand your assumptions - where did you get them from?? What architecture problem in web mdoule are you talking about?? In web code, we are not able to solve the problem I described above: "What about if user does attach to some server (manually using Attach action) creates some real Java breakpoint and uses swing browser (manually) to reach some page? What then? Then there's no web code in the process, only debugger and swing browser are in the way. I believe this patch must be set for all dbg sessions." So according to 3) of your "axioms" I still suggest patch in debuggerjpda or swing browser.
Two points: It is a regression caused by commits in debugger modules. Though it was a poor hack it worked in the past. I see three attempts from Hanz to assign this bug to a different modules than debugger.
Note that a few days ago I committed code to make the Swing browser not call JEditorPane.setPage() from the AWT thread, which is what the AWT thread is doing in the stack trace. This issue may no longer be a problem. Please test it.
I was able to reproduce in todays build.
Please post a new thread dump - it should definitely be different. Also: Is there an actual deadlock here? "AWT-EventQueue-1" prio=7 tid=0x034a6800 nid=0x890 runnable [0x0439f000..0x0439fce8] at java.net.SocketInputStream.socketRead0(Native Method) doesn't look like one (not to mention that it should not happen in AWT at all any more). If the synchronization of reloadDocument() is an issue, that could probably be handled a different way - the only things that need their access protected are the fields "loadingURL" and "pendingURL".
Tim. this is not usual deadlock. The problem is that there is a debugged server that stopped at a breakpoint. Our IDE read the stream from URL connection but now it cannot read further as the stream producer is stopped. It might be resumed when we update our UI and we let the server run again. But the debugger needs AWT thread to run the continue/step actions:
So, Tim. Will you fix it in SB, or should I apply this old patch in debugger code? And do you think that this patch is safe? I have heard that it has some secondary impact (html redirection does not work).
Libor, can you try it with JDK1.5 builds? I saw some changes to avoid URL connection redirecting performed in AWT thread. The only build containg the Tim's change in Swing browser so far is tagged BLD200407222055. Did you Martin tested with this build?
I tested with my own build - built from today's updated sources.
Please reproduce the hang and attach a thread dump to this issue - it should definitely be different now, so I'd like to know where it's hanging. Hans, am I correct that you could solve this problem simply by adding 1-2 System.setProperty calls to the debugger's code?
Created attachment 16451 [details] new stack trace
I always ran it on JDK1.5.0.
Tim, as I wrote, I can apply some old patch provided by Jesse. But I am not sure if the patch is safe, and if its the best solution.
The new thread dump is not from the current trunk: at javax.swing.JEditorPane.setPage(JEditorPane.java:392) at org.openide.awt.SwingBrowserImpl.setURL(SwingBrowserImpl.java:189) Here is line 189 of SwingBrowserImpl: } There is no call to setPage() from SwingBrowserImpl.setURL() anymore, this is done in another thread. In summary: Please do a cvs update and a clean build of openide, and try it again. Then, if it's *really* still a problem, I think the debugger should use the existing workaround. I suspect you won't need to, but maybe some other blocking call still happens on the AWT thread later. This is far too much time for three people to be spending on something this trivial, when there are far more serious bugs for all of us to work on. We have a fix, it was safe before, there's no reason to think it isn't now.
Created attachment 16454 [details] really new trace
Created attachment 16456 [details] A patch - something to try
You can try the attached patch - it depends on two things: 1. That boolean writes are atomic, and thus thread-safe. 2. That the code will enter updateTitle() first and getStream() second, and if that happens, it will use FilteredInputStream, just as the patch does. I'm not sure such black magic is at all a good idea. Hans, as far as I can tell, Jesse's patch is perfectly safe. The most sensible thing to do here would be to use it.
Created attachment 16458 [details] patched trace - no better
OK. Jesse's patch is back. But I can not verify it - JSP Line breakpoint does not work for me. cvs commit -m "46287: IDE hangs during JSP debugging with Swing browser" JPDADebuggerImpl.java (in directory C:\Hanz\Dev\trunk\debuggerjpda\src\org\netbeans\modules\debugger\jpda) Checking in JPDADebuggerImpl.java; /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/JPDADebuggerImpl.java,v <-- JPDADebuggerImpl.java new revision: 1.45; previous revision: 1.44 done
Works well for me with Hanz's patch. Hanzi, it could have taken 2 minutes, so this could have been already fixed 6 days ago!
Not correct. 1) This is not solution, this is not very correct path. Html redirection does not work when debugger is running, as I know. We should try to find some real solution. 2) I can not simply take some code I am not author of, and put it somewhere. SwingBrower maintainer should maintain SwingBrowser patches.
Maybe we should just remove the Swing browser option from the IDE's GUI. I can't think of any compelling reason to use it. It's not a very good browser at all, and everyone is going to have a better one. As this bug demonstrates, it is inherently not implemented safely: it makes network calls from EQ.
forgot to mark as verified