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 debugging remotely if the remote host is configured to use Smart Secure Copy then whin debugging with dbx one gets two tabs for every file, one local and one in ~/.netbeans/remote/... Both tabs are editable! I checked CND-gdb when it's doing remote debugging and it doesn't seem to suffer from this. Ergo there's some filename translation that needs to happen in dbxgui which isn't happening. CND folks ... any pointers?
most probably you should use pathMapper from Execution System ExecutionEnvironment execEnv = ...; pathMap = HostInfoProvider.getMapper(execEnv); pathMap.getRemotePath(...);
I still can not reproduce the issue but I guess it happens due to the problem in pathmapping (like in bug #179466)
Yes, it is a pathmapping problem. To reproduce force dbx to visit a file. There are many ways to accomplish this: (dbx) func foo Where foo is a function in a file which hasn't been opened by the editor. (dbx) file foo.c Where foo.c is a file which hasn't been opened by the editor. (dbx) stop in foo; run dbx will attempt to show foo.c All of this makes me nervous about SSC because you cannot hide it in the dbx (or gdb) commandline. Everything which appears in the gui can be fixed but stuff that appears in the cmdline will use all the ~/.netbeans paths.
*** Bug 179608 has been marked as a duplicate of this bug. ***
details: http://lessing.sfbay.sun.com/hg/toolshg/rev/85b1f618f241 Building up on the fix for 179467 we follow these rules: - Pathnames on their way out from the IDE to the engine will go through localToRemote(). The engine will always see pathnames in their remote form. Critical places: o RunToCursor o File out-of-date notification. o Handler experts. o Gdb -f disassembly requests. - Pathnames arriving from the engine into the IDE will go through remoteToLocal(). The IDE will always see pathnames in their local form. Critical places: o Location constructor which captures incoming data on bpts, home and visit locations as well as all RTC data. o Stack data (which doesn't use Location). o Fix and continue ... although more issues remain. o File saving. o Handler experts. The tasks performed by localToRemote() and remoteToLocal are distinct from the task performed by dbxgui.utils.FileMapper which seems to be concerned with converting windows style notation to unix style notation. FileMapper is not applied as extensively as localToRemote() and remoteToLocal. To test this stuff with gdb I created a new account, 'ideuser', on machine parra with our usual uadmin password. No pathmapping is done under dbxtool! Incidentally ... - localToRemote() and remoteToLocal() take a new parameter to help with tracing which can be turned on using the option -J-Dcnd.nativedebugger.PathMap.debug=true