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.
Created attachment 93022 [details] source code with invalid breakpoints, but stop a one of them Not able to submit breakpoint LineBreakpoint but it should because "step by step" stops at that point. the debugger console says: Not able to submit breakpoint LineBreakpoint FindRepePipe.java : 224, reason: No executable location available at line 224 in class com.softenido.findrepe.FindRepePipe$1. Invalid LineBreakpoint FindRepePipe.java : 224 but as you can see at the attached image is stopped at that poit. you can browse source code at: http://code.google.com/p/softenido/source/browse/#svn/tags/findrepe/0.7.0 or checkout it with: svn checkout http://softenido.googlecode.com/svn/tags/findrepe/0.7.0 findrepe-0.7.0 bug tested on O.S: WindowsXP and Ubuntu Netbeans: netbeans 6.0.1, 6.7 and 6.8 java: 1.6.0_10, 1.6.0_13, 1.6.0_17
Reproduced using: Product Version: NetBeans IDE 6.8 (Build 200912041610) Java: 1.6.0_17; Java HotSpot(TM) Client VM 14.3-b01 System: Linux version 2.6.28-17-generic running on i386; UTF-8; en_US (nb) Line 224 does not accept breakpoints, but I can get program counter on the line using Step Out. Steps to reproduce: 1) Checkout and open the FindRepe project 2) Open project properties, category Run and add a path to a non-empty directory to Arguments text field 3) Open FindRepePipe.java 4) Add line breakpoint to line 224 5) Add line breakpoint to line 77 6) Debug project 7) Debugger stops on line 77 (Debugger console says Invalid breakpoint on line 224) 8) Invoke Step Out 9) Current PC is on line 224
I guess that this is a bug of the compiler. In getFileHashBySize() method there are four anonymous inner classes that extend PipeLine. One would expect that the first inner class is named $1, the second $2, the third $3 and the fourth $4. This is actually what ElementUtilities.getBinaryName() tells me. But the reality is different. Javac decides to put the first inner class into $4, the second into $3, the third into $2 and the fourth into $1. Due to this, breakpoints do not work in these classes, because we search for bad locations. Can this be fixed in ElementUtilities.getBinaryName()? Or is it a javac defect?
Using javap I've found the order of inner classes depends not in source code but in bytecodes. Due every instance of a class is passed as parameter to the constructor of the previous class, the order is inverted. Take a look to javap -verbose FindRepePipe or javap -verbose FindRepePipe$4 using javap and jdb I've attached correctly the breakpoint, so I think it should be posible to do it programatically.
I've tried it in Eclipse Ganimede 3.4.2 and breakpoints stops properly, so it's possible to do it programatically.
Thanks for the report. I changed the way the anonymous innerclass numbers are assigned: http://hg.netbeans.org/main/nb-javac?cmd=changeset;node=2b8141320844 Became part of jet-main in: http://hg.netbeans.org/jet-main/rev/b1c5c88666fb Martin, this might break the anonymous innerclass numbering in some cases - please let me know if you see something suspicious. Thanks.
Integrated into 'main-golden', will be available in build *201004020200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/b1c5c88666fb User: Dusan Balek <dbalek@netbeans.org> Log: Issues #179151, #182895, and #183028 fixed.