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.
When a web application is being run (via F6 or 'Run Main Project') in the middle of attached debugger session, the IDE completely freezes. Steps to reproduce this: ------------------------ - You can use test project from issue 59030 (there is also detailed description howto deploy a webapp to SJSAS) - Deploy the application on SJSAS - In the NB IDE, open the project. - Set SJSAS as server for this project. (This can be done in the project properties, in the 'Run' section. The SJSAS has to be added first in the 'Runtime->Servers section') - Now open the servlet0.java file, and place a breakpoint inside. - Attach debugger session to the SJSAS - Run the project in your web browser, eg. via http://localhost:8080/debug_project/NewServlet - The program counter should be visible in the opened 'servlet0.java' file, exactly on the set-up breakpoint. - Now press F6 to run the program. - The IDE now freezes. I'm adding a thread dump. System Specs: -------------- Sun Solaris9 JDK 1.5.0_03 NB IDE 4.1 200505031930 (fcs) using sjsas_pe-8_1_01_2005Q1-fcs-bin-b04-linux-18_feb_2005.bin for remote server
Created attachment 22264 [details] thread dump
Initiating an HTTP connection in AWT is really awful. This is not a problem of debugger. Moving to J2EE.
Please adjust the version as appropriate.
It's 4.1, I've found it. Next time, please specify the "Version" field also.
Moving to Appserver for now. Looking at the stack trace, I see two solutions 1/ move the web project actions (run/debug) outside the AWT thread, or 2/ eliminate the code that connects to server from the isDebugged() check inside the appserver Which solution is correct?
2 other options: (1) Have J2eeModuleProvider.getServerDebugInfo not calling StartServer.getDebugInfo directly but though ServerInstance to access the debug info cache there. (2) Better yet, expose ServerInstance.isSuspended() through J2eeModuleProvider or Deployment for all devmodules to use.
before jumping to conclusions, I think the key point here is the 'manual' attach in debug mode... If I remember well, this type of bug was filed a long time ago, and I think it was fixed to the automatic attach in debug mode (via debug menu) for web app. I need this info: what is the name of the machine you entered in the 'manual' attach in debug mode window? Does this name really match the name of the server instance declared in the runtime tab? The test for debug mode might use this machine name so the 2 must match.
There was some issue for the situation when debugger stopped at bp and user tried to start server with Start/Stop Server dialog. I implemented ServerInstance.isSupended() method which is there used for suspended state detection. I think that general problem is that client themselves implement the logic of a server state detection (J2eeModuleProvider, WebActionProvider..) and ServerInstance has really terrible not well documented interface. My opinion is that detection logic should be implemented on the server instance or server plugin side. If this is impossible for now I would suggest to try to use ServerInstance.isSuspended() method on the client side.
to ludo: the names of the mashines match (I'm using localhost).
Really link to P1 bug 63435...I think... A fix can address both issues.
http://www.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentManager.java?r1=1.12&r2=1.13 and others fix this.
I know it's a rather obscure usecase ;) But following the steps to reroduce above, I'm still able to reproduce the deadlock. Thus, I have to reopen.
Which build/OS did you use to reproduce the bug?
Solaris and win xp
I hope this is now fixed. Checking in appsrv/src/org/netbeans/modules/j2ee/sun/api/SunDeploymentManagerInterface.java; /cvs/serverplugins/sun/appsrv/src/org/netbeans/modules/j2ee/sun/api/SunDeploymentManagerInterface.java,v <-- SunDeploymentManagerInterface.java new revision: 1.4; previous revision: 1.3 done Checking in appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentManager.java; /cvs/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentManager.java,v <-- SunDeploymentManager.java new revision: 1.15; previous revision: 1.14 done Checking in appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/StartSunServer.java; /cvs/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/StartSunServer.java,v <-- StartSunServer.java new revision: 1.7; previous revision: 1.6 done
I'm still able to reproduce in 200509191800, JDK 1.5.0_05, solaris10/sparc.
Obvioulsy, you are doing a click on the IDE I might not do. It would be nice if you can validate the described steps, particular about how you deploy (run or deploy or debug menu) Feel free to change the priority according to your evaluation. Attach your ide log as well as zip the userdir/config/J2EE dir, if you can...
Also, please when you reproduce this, attach a new threads dump so that I can analyse more with what is now in trunk
Detailed stepes to reproduce: ------------------------------ 1) Start SJSAS in debug mode (with --debug flag) 2) Start the IDE 3) Prepare your webapp and compile it 4) Using your web browser, navigate to SJSAS admin console (ie. localhost:4848) 5) In Webapplication section, use the Deploy wizard to deploy it 4) In project properties, 'Run' section, ensure that sjsas is selected 5) Attach a debugger session via 'Attach debugger...' button 6) Place some BP somewhere (ie. inside index.jsp, in a servlet), simply somwhere where you expect them to be hit 7) Run the application in your web browser (ie. localhost:8080/app_name) 8) Wait for the debugger to hit the breakpoints 9) Now press F6 to run the application -->deadlock [200509201800, JDK 1.5.0_05, solaris10/sparc]
Created attachment 25016 [details] new thread dump
If I attch to localhost and I register localhost, the ide throws an exception If I attach to preston (my machine's proper name) and register localhost, it hangs. Solaris 8, JDK 1.4.2_09
Created attachment 25133 [details] message.log of localhost/localhost exception
Created attachment 25134 [details] thread dump for localhost/preston deadlock
I don't want to mark it as closed yet, but a possible fix was integrated yesterday... Since the dump threads are different than on our side, it's best if you try to reproduce it with the current trunk build and let us know if from your stand point the bug has been fixed. Thanks
reopen if you can reproduce. A temptative fix was integrated.
I consider it fixed. In 200509281800, the deadlock cannot be reproduced - Deployment error message is shown instead. Thanks for your effort.