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.
this might be a showstopper for 67beta if confirmed by debugger team build: Product Version: NetBeans IDE 6.7 Beta (Build 200904192254) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 maybe related to #153789 steps: 1. create your own method in Servlet 2. call method from processRequest and toggle breakpoint to that line 3. use F7 to step into result: F7 is behaving in the same way as Step Over. Shift+F7 is behaving correctly expected result: F7 steps into the method I used Webjpa sample application and added method: public void myMethod() { System.out.println("mymethod"); System.out.println("mymethod"); System.out.println("mymethod"); System.out.println("mymethod"); System.out.println("mymethod"); } i called this method from line 81.
Reproduced.
it's a showstopper for 67beta. let me know when fixed in trunk I'll try to verify right away.
I tried the same in 6.5 and worked perfectly. Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02
It's strange that it worked fine in 6.5, perhaps something has changed in our Step Into algorithm. According to my observations so far it does not look like a NetBeans defect to me, but I did not prove it yet. The problem is, that we do not receive some breakpoint event. We do receive it (and Step Into works correctly) in the same class when executed from main() method, like a standard J2SE application. When the same class is executed as a servlet, the Step Into does not work. I tried to reproduce via jdb, but was not successful yet, since it looks like I'm not able to submit a breakpoint at an arbitrary code location. :-( IMHO this will not be fixed today. :-(
The same problem is present in NetBeans 6.7 m2. I did not find out yet why the breakpoint event does not arrive. I'm not able to reproduce the bug on a test debugger outside of NetBeans.
This does not work even in netbeans-7.0_m1-200812180001 (Build 200812180001) (to confuse everyone, this was not renamed to 6.7 m1). Therefore this bug seems occur since the early 7.0 (now 6.7) development.
I suggest this *not* be marked as a beta stopper, since I do not think this can be resolved soon.
If the same issue is reproducible in M3 I agree with Martin(not stopper for this Beta), Filip could you please doublecheck it ? @mentlicher: even if we decide to not fix it into Beta - it has to be resolved ASAP.
OK. Based on comments from mentlicher I agree this is not beta stopper.
A little progress: this issue does not occur on JDK 1.5. It seems to be specific to something what we do on JDK 1.6 only. Since debugger functionality is more rich on JDK 1.6, it's likely that this bug is triggered by some JDK 1.6-specific call. This gives us at least some hint where to look for the source of the problem.
Product Version: NetBeans IDE 6.7 Beta (Build 200904192254) not sure this is gonna help you guys ... or just confuse a bit more :). Anyway: attached files: Testcase 1: 163249_testcase1_example.java Testcase 2,3,4: 163249_testcase2_example.java Testcase 1 Sample Project: ServletExamples JDK: 1.6.0_13 and 1.5.0_18 J2EE: J2EE 1.4 Server: Tomcat 6.0.18 result: reproduced - F7 didn't work on any breakpoint at all. it doesn't look like it depends on project's JDK. breakpoints: line 38, 45, 50, 78 Testcase 2 Sample Project: ServletExamples JDK: 1.6.0_13 J2EE: J2EE 1.4 Server: Tomcat 6.0.18 what did I do: I toggled breakpoints on lines written below and was trying to step into every method on every line from the first breakpoint was reached to the end of method result: reproduced - F7 didn't worked BUT it WORKED on line 77 or 78. strange. breakpoints: line 52, 57 Testcase 3 Sample Project: ServletExamples JDK: 1.6.0_13 J2EE: J2EE 1.4 Server: Tomcat 6.0.18 what did I do: the same as testcase 2 except breakpoints on different lines result: reproduced - F7 didn't worked BUT it WORKED on line 51 breakpoints: line 45, 47, 52 Testcase 4 Sample Project: ServletExamples JDK: 1.6.0_13 J2EE: J2EE 1.4 Server: Glassfish v2.1 what did I do: the same as testcase 3 except server has changed result: reproduced - F7 didn't worked BUT it WORKED on line 47 breakpoints: line 45, 47, 52 Is there something else I could test?
I have made some change, that made the Step Into to work for me - changeset: 126797:8c114c175c97 http://hg.netbeans.org/main/rev/8c114c175c97 I would not call it a fix and this issue should be a subject of further investigation even if this makes it to work. Can you please test this if it fixes the problem for you as well? If not, can you please run NetBeans from console and look if there are some error messages after Step Into steps over? Thanks.
FYI: Thanks Filip for your tests. It's strange that it does not work neither on JDK 1.5 for you. Can you please try to attach to the Glassfish server via debugger as a remote attach? Instead of Debug on the project, start the server in debug mode from Services tab, in the output find the line: "Listening for transport dt_socket at address: xxxxx" Start another NetBeans with a different user-dir, open the debugged project, and attach debugger to the xxxxx port copied from the server output. In this case Step Into works correctly for me. Can you please check this as well?
sure. you'll get tests result in the weekend so you will have some status for Monday then. Thanks a lot!
Integrated into 'main-golden', will be available in build *200904250201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8c114c175c97 User: mentlicher@netbeans.org Log: #163249 - I do not understand this "fix" at all, but this change (which should not change anything in fact) solve the Step Into issue for me. Let's see if this magically starts to work for others as well. In any case, this issue should be a subject of further investigation, this is not the right fix for sure!
Created attachment 80962 [details] 163249_testcase1_example.java
Created attachment 80963 [details] 163249_testcase2_example.java
sorry for delay. I did test you asked for and here you go some result: 1. Attached Debugger I Product Version: NetBeans IDE 6.7 Beta (Build 200904192254) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 Project was using jdk 1.5.0_18 RESULT: OK 2. Attached Debugger II Product Version: NetBeans IDE 6.7 Beta (Build 200904192254) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 Project was using jdk 1.6.0_13 RESULT: OK
previously mentioned testcase has been verified on Product Version: NetBeans IDE Dev (Build 200904270201) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 VERIFIED Testcase 3 (referring to post from fzamboj Thu Apr 23 15:17:17 +0000 2009) Sample Project: ServletExamples JDK: 1.6.0_13 J2EE: J2EE 1.4 Server: Glassfish v2.1 what did I do: breakpoints on lines below result: worked as expected breakpoints: line 47, 52
Thanks a lot for the tests and verification. So the "fix" works for you as well. I'd be very pleased if someone can explain to me how this "fix" actually works!
> I already took the survey, but missed reporting this issue. When using the jpda debugger, I cannot step into a method. This has worked correctly in the past, but I don't think it's worked correctly since the beginning of NB 6.7. I was unsure, but after trying to use the debugger again today, I can tell you step into, when there is only one method in the line (in which to step), does not work.
are you still talking about web projects or you have another kind of project? Was that method servlet? And, what build are you using, please! Sorry for so many questions ;) Thanks a lot!
Reopening this issue is a result of a discussion in the nbusers mailing list. The build is RC2 I believe. However, I tested this on a j2se project in RC2 (Build 200906042131) as well as yesterday in RC3 (Build 200906110001), but Step Into worked just fine. @wbossons: as fzamboj wrote, could you please add more info?
Ah, forgot to mention, both time stested on Linux, jdk 1.6u14.
No wonder that this issue still appears sometimes, the "fix" at http://hg.netbeans.org/main-golden/rev/8c114c175c97 was not meant really seriously. But it helped in some described cases at least. wbossons, are you debugging a servlet? Can you provide some application sample where this problem occurs? Thanks.
@reporter: we need more information, please. Could you point us where exactly it doesn't work? This problem occurs in special cases only and we are not really able to determine them. Therefore, all hints are appreciated. Thanks a lot!
Working on a correct fix into 6.8. This should be considered as a candidate for patch into 6.7. It looks like I've finally identified the problem - this bug occurs only when the servlet is deployed for the second (or more) time to the server. When the class of the servlet is present several times in the server VM, we mistakenly work with the first instance, but other instances are being executed. This is why the supplemental breakpoint that we submit for intelligent step into is missed.
Hopefully finally fixed in changeset: 135346:34df09de73ee http://hg.netbeans.org/main/rev/34df09de73ee Please verify that it works O.K. now, even after several deployments.
Integrated into 'main-golden', will be available in build *200906180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/34df09de73ee User: mentlicher@netbeans.org Log: #163249 - Step Into fixed for servlets in a correct way. Old "unlogical" fix removed. Step Into now works with the actual active class, not one found among all classes in the system.
Verified on NetBeans IDE Dev (Build 200906180201)
The fix has been ported into the release67_fixes repository. http://hg.netbeans.org/release67_fixes/rev/fff0358818cc
*** Issue 168313 has been marked as a duplicate of this issue. ***
cannot be verified in 6.7.1. Product Version: NetBeans IDE 6.7.1 RC (Build 200907150227) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 1. run sample "ServletExamples" 2. place breakpoints on lines 41,45,49 in HelloWorldExample.java 3. try to step into - I succeeded to step into on line 49 only Class where breakpoints were set extends HttpServlet here X marks lines where breakpoint is set and I tried to step into. Y denotes place where I suceeded to step into. public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { ResourceBundle rb = ResourceBundle.getBundle("LocalStrings",request.getLocale()); X response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<html>"); X out.println("<head>"); String title = rb.getString("helloworld.title"); Y out.println("<title>" + title + "</title>");
P1 due need to fix to 6.7.1
This was verified in trunk before. Does it mean it only does not work in 6.7.1? Or is it in fact not working in trunk either?
Yep, it's reproducible in Product Version: NetBeans IDE Dev (Build 200907160201) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 It stepped into on line 45 this time.
The originally reported problem says that it is not possible to step into "own" methods in a Servlet. This has been fixed and it is no longer reproducible. The newly detected problem is different, step into sometimes fails to detect the nearest available source file and stop in it. In the scenario described above, when stepping into out.println("<head>"), source of println() is not available, since 'out' is an instance of com.sun.enterprise.web.connector.coyote.PECoyoteResponse$PECoyoteWriter. The nearest available source is java.nio.CharBuffer which of wrap() method is reached by nested calls. Stepping into such methods is not a common use case. I think, this is not a showstopper and it would be sufficient to fix it in nb6.8, decreasing priority to P3.
Based on discussion I had with Dan I confirm that this is not a showstopper anymore and the most important part (stepping into own method called in servlet) has been fixed. Thus this issue is 67patch1-verified and I'm looking forward to seeing a final resolution in 6.8 ;)
Filipe, please report the problem that you found out as separate issue. Thanks, petr
Filip, please report that problem as separate issue - this one is fixed/verified
v
issue #168707 filed