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.
The new version of the C++ module (1.4.3) distributed via Automatic Update in the IDE causes remote breakpoints not to function. The log shows that NetBeans is not using the remote path when setting breakpoints, but the local path. Log snippet below: ... 111-break-insert -f /Volumes/LB1/eskimo/EskimoD/server.cpp:23 109&"info proc\n" 109~"process 4197\n" 109~"cmdline = '/root/eskimo/EskimoD/dist/Debug/GNU-Linux-x86/eskimod'\n" ... ... &"No source file named /Volumes/LB1/eskimo/EskimoD/server.cpp.\n" 111^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="/Volumes/LB1/eskimo/EskimoD/server.cpp:23",ti mes="0"} ... NetBeans is running under Mac OSX Leopard (10.5.6 - gdb-962) and compiling/debugging against Fedora 9 x64 (GDB 6.3.50-20050815). This issue is not limited to this project, and a simple hello world project also has the same issue. Also discussed here: http://forums.netbeans.org/viewtopic.php? t=8638
This also affects the nightly builds and 7.0M1, since they already use the 1.4.3 module version.
Do you mean, this is regression after 6.5 made Auto Update? And before Auto update it worked fine?
Yes thats correct. If you download the current GA release of 6.5, remote breakpoints work. As soon as you Auto Update, they get broken.
The regression happened after fixing issue #151761
fixed in the changeset: http://hg.netbeans.org/main/rev/4b3d0cdf0422
*** Issue 158762 has been marked as a duplicate of this issue. ***
Remote breakpoints now work but current position is not shown while debugging in makefile based projects.
Current position was not shown due to old version of Gdb installed on the remote host. After installation of a newer Gdb everithing works OK.
integrated into release65_fixes with: http://hg.netbeans.org/release65_fixes/rev/ee8e683f1548
in 6.5.1 clone breakpoints do not work for makefile (work fine for managed projects) based projects on Solaris_x86/Solaris_sparc configuration when project is created on local machine in /export/home/tester and is mapped to /net/sqao24/export/home/tester on remote host.
Somehow that wrong behavior is not reproducible any more. Please ignore the previous comment.