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.
Summary: | Re: Failure to connect to C/C++ Development Host | ||
---|---|---|---|
Product: | cnd | Reporter: | twhite <twhite> |
Component: | -- Other -- | Assignee: | Sergey Grinev <sergius> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | sustaining |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
twhite
2008-11-18 14:41:21 UTC
I noticed on the development server that there were 5 successful SSH connection reported, while I was trying to add the server. I also made my project local to the PC and shared it via NFS to the development server. Again, it failed to get past the "Initializing.." message. I saw in another ticket, where login messages can confuse the connector. So, I removed all messages during the login process (including those generated by SSH -- last login). Now when I login from the terminal app, I see only my prompt. I am using the bash shell, and my PATH contains both netbeans and SUNWspro binaries(on the server). What exactly is it trying to do when it creates a development host???? I can not find any documentation anywhere on this. Glancing at the code, it certainly seems that this is a big dangerous. RemoteServerRecord.stateLock is acquired, and then if a RemotePathMap is created, then the RemotePathMap.pmtable and map locks are acquired. So with those three locks, the preferences are gotten. It is hard to tell where it goes from there. It also does some other calls, which should not take too long...but might. -- I had Tom run it again and obtain a thread dump from when the "add server" dialog is trying to connect and never completing. It is hanging and this is the crux of the problem: HostMappingProviderWindows Process process = Runtime.getRuntime().exec("net use"); //NOI18N InputStream output = process.getInputStream(); process.waitFor(); The input stream is obtained first and then the thread waits for the process to complete. If the buffer in the input stream is too small, the running process cannot complete because there is nowhere for the output to go. However, the way the code is written, the stream will not be read until the process has completed. So we have a producer with no consumer and wait. Here is what Tom's "net use" command displays: Status Local Remote Network ------------------------------------------------------------------------------- O: \\192.9.201.235\opt\SUNWspro Hummingbird NFS Unavailable Z: \\elkhorn.dev.donnell.com\users1 /P:600 /D:700 /R:32768:8 /W:32768:8 /L:c /U /S /M:p /A:u /c:o /f:1?1?Donnell Systems Hummingbird NFS The command completed successfully. Why hummingbird NFS has such a long string is on them, but since NFS mounts are a prerequisite, this can happen. Probably this could be changed to something like the following, without modifying too much other code. The Process API needs to be verified that it works like I think it does, but you will get the gist. Process process = Runtime.getRuntime().exec("net use"); //NOI18N InputStream output = process.getInputStream(); byte[] buffer = new byte[8192]; ByteArrayOutputStream baos = new ByteArrayOutputStream(); int x = output.read(buffer); if (x == -1) { //throw some exception here } baos.write(buffer,0,x); while (x != -1) { x = output.read(buffer); if (x != -1) baos.write(buffer,0,x); } try { int exitVal = process.exitValue(); if (exitVal != 0) { //throw some exception here } } catch (IllegalThreadStateException ex) { //Process is not done, but should have been } byte[] outputBuffer = baos.toByteArray(); output = new ByteArrayInputStream(outputBuffer); //continue with old code ------------- Where is hung for Tom initially: Name: Default RequestProcessor State: RUNNABLE Total blocked: 0 Total waited: 25 Stack trace: java.lang.ProcessImpl.waitFor(Native Method) org.netbeans.modules.cnd.remote.mapper.HostMappingProviderWindows.findMappings(HostMappingProviderWindows.java:66) org.netbeans.modules.cnd.remote.mapper.HostMappingsAnalyzer.populateMappingsList(HostMappingsAnalyzer.java:103) org.netbeans.modules.cnd.remote.mapper.HostMappingsAnalyzer.getMappings(HostMappingsAnalyzer.java:69) org.netbeans.modules.cnd.remote.mapper.RemotePathMap.init(RemotePathMap.java:121) - locked java.util.HashMap@10cc039 org.netbeans.modules.cnd.remote.mapper.RemotePathMap.<init>(RemotePathMap.java:88) org.netbeans.modules.cnd.remote.mapper.RemotePathMap.getMapper(RemotePathMap.java:70) - locked java.util.HashMap@200ff6 org.netbeans.modules.cnd.remote.server.RemoteServerRecord.init(RemoteServerRecord.java:154) - locked java.lang.String@f7e5b2 - locked org.netbeans.modules.cnd.remote.server.RemoteServerRecord@1ea41b5 org.netbeans.modules.cnd.remote.ui.EditServerListDialog$1.run(EditServerListDialog.java:161) org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572) org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997) Please do not paste large portions of text in the description next time - attach them as separate file... Sergey, Pls take a look, if it is something new or it has been fixed in FCS. LL Fixed by http://hg.netbeans.org/main?cmd=changeset;node=e4d2382c6650 Thanks for the one of the most detailed bug reports I ever seen. The root all evil was in excessive process.waitFor() call. I've nominated this bug for release 6.5 patch 2, so I hope it will be available soon. Current workaround is to temporary remove all network shares on Windows except one before creating remote host in NB. *** Issue 153621 has been marked as a duplicate of this issue. *** *** Issue 153762 has been marked as a duplicate of this issue. *** Integrated into 'main-golden', will be available in build *200811270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e4d2382c6650 User: Sergey Grinev <sergius@netbeans.org> Log: fixed #153389 Re: Failure to connect to C/C++ Development Host ok in Build 200812150201 fix backported into release65_fixes branch http://hg.netbeans.org/release65_fixes/rev/e493cc9ca64c verified in patch2 |