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.
Steps to reproduce: - add a remote host and set it as default - create any sample application (e.g. Welcome) - build it - run it, it runs successfully - do step into Result: "Choose Executable" dialog appears. Generally user does not know where executable is placed on the remote host. Moreover that dialog appears every time when user starts remote debugging.
The remote host is configured to use "Smart Secure Copy" type of synchronization.
I'm not having any luck reproducing this. Alexander, can you please ... - Check and see what the Build->Linker->Output property value is in your failing case? It's usually something like. ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/welcome_1 - Does the DebugExecutable dialog pre-fill the executable pathname with anything? What is it's starting directory? - When things work dbx sees: debug /home/ivan/.netbeans/remote/djomolungma-SunOS-sparc_64/export/home/test\ /SunStudioProjects/Welcome_1/dist/Debug/SunStudio-Linux-x86/welcome_1 Could it be that under testing the .netbeans is elsewhere and is therefore inaccessible? - Is the local userid the same as remote userid? That might govern where the .netbeans goes. - Even if the userid's are the same the remote machine might have a non-ldap user with it's own home which would be ditinct from SWAN-wide home?
I checked, Build->Linker->Output property value is ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/welcome Choose executable dialog does not pre-fill File Name field but opens /export/home/tester as a starting folder on the local machine
if I connect to remote server as "tester" and build the project I get: Copying project files to /export/home/tester/.netbeans/remote/amkar-SunOS-x86_64/ at tester@spb-nero.russia.sun.com:22 ... If I use my own account I get: Copying project files to /home/ap153252/.netbeans/remote/amkar-SunOS-x86_64/ at ap153252@spb-nero:22 ...
And you get the dialog regardless of whether you login as tester or ap153252? My suspicion is as follows. The Dialog ispopped up when the IDE checks for the file given to it by the project and if it's not found or is inaccessible puts up the popup. This is prolly justs one very old leftover logic. So if /export/home/tester/.netbeans or /home/ap153252/.netbeans on the remote machine are not directly accessible, or have read permissions, you will get this popup. I'll try this theory later today when I get into work.
Yes, I get the dialog in any case with any account and on different machines. Please note that I never get such dialog in CND on the same machines with the same accounts. I do not get the dialog either if I just run the same remote applications in current SSIDE. Appearing of this dialog is strongly dbxgui specific.
Ivan, is it true that DataNodes are used in debug actions only to tests mime type? Is it so necessary for executable? Can we catch debugger error and do not do this check during remote?
Yes, I think so. I was thinking by "fixing" this by removing all that Node stuff. In fact no pathmapping is needed here since the executable name passed in is apparently the "remote" name. (this seems like an exception to my proposal of xlating everything only when they go to the external engine) Another role of the Nodes in the code is for initiating actions from Nodes which got me into bug #179771. So before I can eliminate Node related stuff we have to agree that we're in general doing away with operations on Nodes and only work with projects. OTOH there was an old bug where the working directory wasn't being checked by the IDE and letting the debugger catch the error didn't quite work so well, but maybe it can be improved. I'll chase all the dependencies and issues as best I can before removing anything. Even if we decide to reintroduce Node level checking later I think it's still best to remove the old grot and add in new stuff in a cleaner was as we need it. What are CND's intentions regarding remote filesystems? Mind you, I think they are unbelievably hard to implement and we should stick to system level file sharing like NFS. This is also the recommendation of NB itself.
changeset : 348:358bf310a6ef It's tricky to reproduce this. - SecurSmartCopy should be chosen. - The remote ~/.netbeans directory should not be accessible from local machine. This is tricky since ~/.netbeans is hardcoded. To achieve this I created a new account, 'ideuser', on machine pamuk. I also had to make the 'ideuser's home directory not be readable by group/all. In the end this happens because DebugProjectAction.performAction() maps a filename to a DO or FO which cannot be found on a local machine. There is some old code there which upon a failed mapping will ask the user to an executable and that's the one we get in this report. To fix, eliminated DebugProjectAction and it's derivative DebugProjectAndStepAction since none are really used as actions. About the only useful thing that DebugProjectAction did was to call DebuggerManager.get().debug(). This is now done in DbxActionHandler. Most of the work performed by DebugProjectAction involves Nodes which isn't relevant because we start with an executable in the caller and end up with an executable as control passes on. Any checking performed in DebugProjectAction was redundant because the Project system pre-checks stuff for us, in ProjectActionSupport$HandleEvents.checkExecutable(). Incidentally ... DebugProjectAction.getMime() was moved to IpeUtils. This function is used by a lot of corefile mgmt code. Test matrix basis: - Debug vs StepInto - valid executable vs invalid executable - localhost vs remote SSC host vs remote NFS host
details: http://lessing.sfbay.sun.com/hg/toolshg/rev/358bf310a6ef