Community
Participate
Working Groups
I have a number of Java projects set up in eclipse checked out of CVS on a HP- UX server. All goes well until I try to add HTTPClient. On screen I see building workspace 25% - cpu hits 100% ( javaw.exe ) and nothing else happens. I've left the PC for over an hour to see if it's just slow. Eclipse error log always reports the same - below. !SESSION May 21, 2004 15:46:22.812 --------------------------------------------- java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -vmargs -Xmx384M -debug !ENTRY org.eclipse.osgi May 21, 2004 15:46:22.822 !MESSAGE Bundle reference:file:e:/eclipse/plugins/org.eclipse.team.cvs.ssh2_0.1.2/ [92] was not resolved This directory exists on the PC and from what I can tell appears to be OK contents wise. Any help wil be very gratefully received
What build are you using?
Can you launch with Java console open (using java.exe instead of javaw.exe), and press ctrl-pause to force VM to perform thread dump ? This will help pointing the finger at the offending component at work. Please reopen once requested information is made available.
Created attachment 11000 [details] thread dump This happens on both 8M and 9M - I can't use 2.1 as it's not compatible with SSH on the HP-UX CVS server. I'm going to give 7M a try now.
I think I've attached the info you ask for. I'm getting the same problem building a workspace in both 8M and 9M. I'm going to try 7M and also try a different CVS repository to try and remove some possible environemntal issues. My real repository is on a HP-UX 11.0 server. The test repository is linux (redhat 9). VM is 1.4.2_04. I'll try installing on W2K as well to see if that makes any difference.
Tried a different CVS repository - same problem.
Suspecting the source indexer to be very very busy. "Java indexing" daemon prio=4 tid=0x007f5c40 nid=0x13d runnable [190ef000..190ef d90] at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.scop eTrialCheck(DiagnoseParser.java:1358) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.scop eTrialCheck(DiagnoseParser.java:1443) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.scop eTrial(DiagnoseParser.java:1309) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.chec kPrimaryDistance(DiagnoseParser.java:691) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.prim aryPhase(DiagnoseParser.java:531) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.erro rRecovery(DiagnoseParser.java:448) at org.eclipse.jdt.internal.compiler.parser.diagnose.DiagnoseParser.diag noseParse(DiagnoseParser.java:358) at org.eclipse.jdt.internal.compiler.parser.Parser.reportSyntaxErrors (Pa rser.java:5405) at org.eclipse.jdt.internal.compiler.parser.Parser.parse (Parser.java:538 4) at org.eclipse.jdt.internal.compiler.parser.Parser.parse (Parser.java:570 8) at org.eclipse.jdt.internal.compiler.parser.Parser.parse (Parser.java:567 3) at org.eclipse.jdt.internal.compiler.SourceElementParser.parseCompilatio nUnit(SourceElementParser.java:1133) at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.indexDocu ment(SourceIndexer.java:75) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocum ent(JavaSearchParticipant.java:72) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocum ent(IndexManager.java:258) at org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute ( IndexManager.java:566) at org.eclipse.jdt.internal.core.search.processing.JobManager.run (JobMan ager.java:367) at java.lang.Thread.run(Unknown Source)
FYI - In M9, in progress view, you can toggle it to verbose mode (using drop down menu), and see the Java indexing activity. I suspect you have a very large source file with syntax errors which we have troubles to process. It must be penalizing everything. Alternatively, we could have a bug in our syntax recovery code, where it would loop forever... can you attach offending source files ?
Created attachment 11016 [details] zipped source files for HTTPClient Full source from project. When I have compiled this it produces only a few warnings.
That was quick ! Actually, all parsing of this unit would be slow, as demonstrated by the stack trace. An obvious answer is to disabled diagnose parsing when unnecessary, like when parsing for indexing, but still the analysis involved in there should be bound in time.
I'll leave it running overnight. My only query is this project builds in 2.1 in a couple of minutes so should it really be so different at version 3.0? I'm also searching through the Help files for the parsing options - will update when I've tried this. Thanks for your assistance.
There is no syntax error inside HTTPClient, so the problem is probably not with this project. Could you give me exact step of your test case ?
David W - my comment#9 about disabling diagnosing for certain parsing was intended for David A. User cannot configure this, we have to disable it internally when irrelevant. The theory is that syntax diagnosis should take very little time, and only on syntactically incorrect code. Try to look for some code with syntax errors. We are aware of another problem where a massive binary file is fed to the parser (incorrectly) and where the parser takes a very long time to figure errors in it.
One of my colleagues has found the problem. It is environmental and is totally my fault so please accept my humble apologies for taking up your valuable time. The source code was originally checked into RCS using a3rd party tool that had UUEncoded it all. This was not immediatley apparent but after leaving the PC processing overnight I was able to check the code today and see it was being retrieved by CVS in the UUEncoded format. The source files were - as you diagnosed above- effectively large binary files and were taking a long time to process. The source code has been removed from the repository and checked in again cleanly - everything works very quickly. Thanks again for all your efforts.
We needs to improve performance of the diagnose algorithm.
*** This bug has been marked as a duplicate of 62453 ***
Then this is a dup of the other problem I mentionned in comment#12. Thanks for clarifying this. Being fault-tolerant is something we should look into.
