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.
Sometimes the duration of Step Into action is very long. It should be investigated and bottlenecks identified. The following are numbers from my measurements of new debugger implementation, together with the numbers of old trunk and current trunk. The three times are times for three consequtive Step Into actions from a given point in my testing project. The numbers with * are supposed to be higher than 100ms because in this case a new file was found and open in editor. W2K: build 200403141900: 2516*, 968*, 78 build 200403231900: 2172*, 19531*, 97 new debugger build: 2563*, 781*, 94 Linux: build 200403141900: 1430*, 555*, 167 build 200403231900: 1483*, 4673*, 75 new debugger build: 13363*, 310*, <tens of secs> The last number on linux is "tens of secs" because it took so long I was unable to measure it precisely. A thread dump from this long period before Step Into completed will be attached...
Created attachment 14174 [details] Thread dump of one occurence of Step Into action taking extremely long time
*** Issue 42716 has been marked as a duplicate of this issue. ***
I'm reproduced with JSP user scenario - tried to stop in jsp on line with some included file and pressed F7 to step into the file. First I thought there's a deadlock, but after ~90 seconds (!) debugger finally stopped in the included file. I checked with 3.6 - 5 secs at maximum. This is a problem. Linux (JDS), jdk1.4.2_04
Created attachment 15998 [details] index.jsp
Created attachment 15999 [details] inc.jsp
To reproduce with jsps: 1. Create web application project 2. Create index.jsp, inc.jsp with the content as attached ones 3. Put breakpoint into index.jsp to line 6 4. Debug main project 5. When debugger stops on bp, press F7 6. Wait, wait, wait, wait ...... after a minute or more debugger finally jumps to inc.jsp
The described action takes some 2 secs on my machine (WXP), will try it on linux too.
I have reproduced it in Fedora, the first Step Into takes ~15 seconds. Tomcat eats 100% CPU, IDE just waits for it. The subsequent steps are OK. You can also start a new debugger session within the same IDE session and stepping will be fine. Once you restart IDE the first step takes again long time.
Martin please find out whether this is caused by compilation of JSPs by Tomcat.
Yes, I'd say it's caused by the compilation. Second attempt lasts less than 2 seconds for me either. But tomcat compiled jsps even in 3.6, so there must be something wrong. I did a bunch of thread dumps (they look all the same) - see attached.
Created attachment 16079 [details] Tomcat threaddumps
They look the same because we just wait for tomcat to finish (compilation or whatever). AFAIK the version of tomcat changed in 4.0, can we try the new debugger with the old (bundled with NB 3.6) version of Tomcat?
OK, I'll try remotely debug 5.0.19 (3.6.) and 5.0.25 (4.0) to see if there's any difference.
Closing as not relevant: 1) First usecase (Antonin): I am not able to reproduce it. Performance of new debugger is similair to old one. Your thread dump is not relevant to debugger. 2) Second one (Martin): This usecase is reproducible, but your description is wrong. The same scenario is reproducible in NB36, I think. The problem is, that execution (in smart stepping mode) under debugger is 5-10 times slower than execution without debugger (and its not fixable on our side). And compilation of JSP takes a long time. I do not see any space for improvements on debugger side in this case. The only think we can do is to add some timeout to the smart stepping implementation. But its not clear solution. Can you try to fix it on your side? Compile all JSPs before debugging, switch off smart stepping in this case, or... And can you fire a separate issue for this problem, with some relevant description? Thanks.
No such long delays in current builds (~200507061800). Closing.