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.
[ BUILD # : 200409301800 ] [ JDK VERSION : J2SE 1.4.2 ] Mounted a not very big (188 files) VSS project and switched to the Projects tab. Tried to expand the project node. The status bar says that the refresh command is running. 100% CPU is consumed for 10 minutes before I killed NetBeans. A restart never got passed half the progress bar. Had to kill it again and remove the most recent file in the "VCSMount" directory to be able to start NetBeans and remove the entry from Versioning Manager. The "_so" file in the "running" directory indicates that all project directories has been quickly traversed, so it seems that strange things happens after that. The consequences of this problem is that versioning a VSS project is impossible.
Created attachment 18127 [details] Log file
It looks that the refresh is somehow broken, it reports strange files in the messages.log file: getCanonicalFile() on file C:\Projects\Build\jasper-targets.xmlDiffing: $\Build\.nbattrs failed. java.io.IOException: The filename, directory name, or volume label syntax is incorrect This seems to be the same problem, that you reported in issue #50382. However, I did not get the IDE into that state yet...
Gunnar, can you please verify whether this still happens after issue #50382 is fixed? Thx.
Yes, the problem still exists with build 200410202002 but there are not any strange messages in the log anymore. The Runtime tab shows the following commands: AUTO_FILL_CONFIG AUTO_FILL_CONFIG Refresh (with "running" icon) LIST_DIR_READER (with "stop" icon) LIST_STATUS_FOLDER_READER (with "stop" icon) Attaching output from the latter two.
Created attachment 18422 [details] LIST_DIR_READER output
Created attachment 18423 [details] LIST_STATUS_FOLDER_READER output
The output looks good. But Refresh is still running forever? Can you please make a thread dump and attach it here? This can be done in the console from which NetBeans are running (run it with nb.exe, that should open the console). Please assure that the console is big enough (set the number of lines to at least cca 500) and press CTRL-Break in the console, while Refresh command is running in NetBeans. I hope that I will finally find out what's going on from that :-) Thanks.
Created attachment 18435 [details] Thread dum as requested
Created attachment 18770 [details] New dump taken with 200410311900
Martin, couldn't that be some yet unknown question problem like we used to have in the past ? Wouldn't it be worth trying to copy execution string of both LIST_* commands and run them on command-line maually ?
From the thread dump it's apparent that there is some deep directory structure in the status cache. This may be a fault of recursive refresh, which provides bad data. In the messages.log there is apparent bug in rec. refresh: getCanonicalFile() on file C:\Projects\Build\jasper-targets.xmlDiffing: $\Build\.nbattrs failed. java.io.IOException: The filename, directory name, or volume label syntax is incorrect which was already fixed as a part of other fix. Gunnar, can you please try the new dev build with a clean user directory? If this problem was caused by rec. refresh, it should dismiss in new dev builds. We're not able to reproduce it here. Thanks. To Jiri: From the command outputs it does not seem that the commands are asking something, it looks like the CPU is consumed by the IDE, not by ss.exe. This corresponds with the thread dumps where a deep directory structure is visible. Unfortunately it's not apparent how the deep structure was created.
OK, tried it with a clean userdir. Same symptomps, same thread dump. Don't know what you mean by "new dev build". Is there a newer than 200410311900? I tried associating a VSS project ($/DOISuite/DOI4) with the local project directory. Still, Refresh runs forever. I also got a number of strange "Error Outputs" from LIST_STATUS_READER: $/DOISuite/DOI4\TextBundle_sv_SE.properties is not an existing filename or project - Correct, that file exists in the structure but several levels deeper. I have qite a few of these files in different packages. $/DOISuite/DOI4\WidgetTextFieldPanel.java is not an existing filename or project - Correct again. The file exists but deep down. $/DOISuite/DOI4\TextBundle_sv_SE.propertiesDiffing: $/DOISuite/DOI4/src/se/grim/doi/desktopAgainst: C:\Projects\DOISuite\DOI4\src\se\grim\doi\desktop is not valid SourceSafe syntax - Correct once more. Certainly not valid SourceSafe syntax. Hope some of this info might be helpful!
Same behavior with 200411072021. I'll attach a new complete thread dump, with a couple of extra dumps at the end, showing just the looping portion.
Created attachment 18806 [details] Dump taken with 200411072021
Hello Gunnar, we are sorry, but the build you used for testing doesn't contain fix of this issue. Build 200411081800 contains the fix. BTW, can you attach the zip file of your project that you use? We hope this can help us to find out where the problem is. Thanks.
OK, I'll try build 200411081800 when it is available for download. I've tried to reproduce the problem in some project that I could zip up and send you. Unfortunately, I can't. The projects that I have problems with are not structurally different in any way that I can imagine would cause a problem. They are just larger. Not significantely though, one of them has only 182 files. Can't send you any of these. There was one thing I noticed though: The .nbintdb files in the problematic projects are much smaller than the one in the project that works. One of them (I'll attach it) contains the following text: "Project $/Test/HTML has no corresponding folderProject $/Test/src has no corresponding folderProject $/XDoclet has no corresponding folder" The SourceSafe repository does have the projects "$/Test" and "$/XDoclet" but I can't see what NetBeans is doing looking at that level, since the project is located at "$/DOISuite/Effie4".
Created attachment 18808 [details] The funny .nbintdb file
Today I built NetBeans from sources (netbeans-4_0-daily-src-200411072021-ide_sources-7_Nov_2004_2021.zip) and inserted a couple of diagnostic prints in "org.netbeans.modules.vcscore.cache.impl.VcsCache" at the entry to "seekCacheDir" and "getDir". Strangely enough I found that the line numbers reported in the thread dumps did not match the source. Seems like the 200411072021 binary isn't built from the exact same sources as the ones in the zip. Anyway, I then created a VSS association for one of my problematic projects. Now refresh worked as expected but that could be because the working folder was completely up to date. I then mapped another problematic project and sure enough, Refresh went into a loop. The output in the log shows that some really weird "paths" are thrown at these poor methods. I'll attach just an excerpt from the log since the complete log quickly became very large. Please tell me if you want me to put in some additional printlns.
Created attachment 18886 [details] Part of the log
Hi Gunnar, it looks like I was able to reproduce this problem! I was just playing with the VSS settings and found that when I set "Act on projects recursively" on, in Tools -> Options -> General tab in Visual SourceSafe GUI, I get exactly the symptompts that you wrote about. The problem was easy to identify and fix. The Refresh did not specify -R- to the diff command and therefore it unexpectedly provided recursive diff when you have that option on. The fix is to add -R- to diff command in LIST_DIR_READER command.
Fixed in trunk: /cvs/vcsgeneric/profiles/vss/src/org/netbeans/modules/vcs/profiles/vss/config/vss.xml,v <-- vss.xml new revision: 1.35; previous revision: 1.34 /cvs/vcsgeneric/profiles/vss/src/org/netbeans/modules/vcs/profiles/vss/config/vssLoc_XX.xml,v <-- vssLoc_XX.xml new revision: 1.29; previous revision: 1.28
Created attachment 19127 [details] The patched VSS profile, please put into <userdir>/config/vcs/config folder and restart NetBeans to take effect.
Gunnar, can you please try the attached patched profile? Be careful when saving the attachment to assure that it's named "vss.xml". Dummy Windows tries to append .txt since I've marked is as a textual file!
Tried the patch and it works! Great! BTW, Firefox doesn't add a .txt extension even when running on Windows. Probably an IE "feature".
Martin, this bug definetely deserves being on 4.0 HotFix AUC ASAP. Do you agree ?
Yes, I do agree. We plan to put on Hotfix AU also issue #51955. We'll have likely the same policy that we used for 3.5: http://www.netbeans.org/community/releases/35/release-fixes.html
*** Issue 52518 has been marked as a duplicate of this issue. ***