Bug 162177 - ecj intermittently fails to parse classpaths correctly.
ecj intermittently fails to parse classpaths correctly.
Status: CLOSED DUPLICATE of bug 199961
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
6
All Linux
high Severity high
: ---
: ---
Assigned To: Andrew Haley
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-30 12:50 EDT by Gary Benson
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: eclipse-3.1.0_fc-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-01 13:32:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Build log from beehive (48.07 KB, text/plain)
2005-07-04 04:44 EDT, Gary Benson
no flags Details
Script to exercise java.util.StringTokenizer (431 bytes, text/plain)
2005-07-04 05:35 EDT, Gary Benson
no flags Details

  None (edit)
Description Gary Benson 2005-06-30 12:50:11 EDT
Description of problem:
ecj intermittently fails to parse classpaths correctly.  The bit that splits the
path on colons fails, so it treats the whole classpath as a file/directory. 
You'll get an "incorrect classpath" message, then your build will fail because
there'll be nothing on the classpath.

Version-Release number of selected component (if applicable):
eclipse-ecj-3.1.0_fc-0.M7.9 and eclipse-ecj-3.1.0_fc-0.RC3.3
libgcj-4.0.0-12, libgcj-4.0.0-13
java-1.4.2-gcj-compat-1.4.2.0-40jpp_30rh

How reproducible:
Fails at different places on different machines, but if it fails at a specific
place on one machine then it'll always fail there.

Steps to Reproduce:
Try and build a package.  nanoxml and perseus-cache fail in beehive but not on
my machine.  joram fails on my machine if you add ship.jonasadapter to the list
of targets on the ant command line.  Or, start up jonas and try and view a JSP
-- the JSP compiler fails on both mine and Mark Wielaard's boxes.

Actual results:
An "incorrect classpath" warning, followed by a failed compilation.

Expected results:
Neither of the above.

Additional info:
I hate bugs.
Comment 1 Gary Benson 2005-06-30 13:11:00 EDT
Actually, the joram failure might actually be because joram's build script is
simply broken.  If so, then perhaps I can narrow down what versions things are
failing on.
Comment 2 Tom Tromey 2005-07-01 16:50:36 EDT
The joram build fails for me because build.kjoram wants midpapi.jar,
which doesn't exist.

perseus-cache seems to build but there are errors about missing
'fractal' imports; so I think it probably has some other problem.

Is this architecture specific?
Comment 3 Gary Benson 2005-07-04 04:44:32 EDT
Created attachment 116322 [details]
Build log from beehive

No, fractal is there: the errors are because ecj is failing to parse the
classpath with the fractal jars in it.

Check the attached log for the line that starts "incorrect classpath".	After
splitting classpaths on colons, ecj performs a file existance check on every
element of the classpath to see if it exists, and prints out an "incorrect
classpath" message for _each_ element that's missing.  The fact that the whole
classpath appears in the message would imply that splitting the classpath on
colons failed.

I'm not sure about the joram error, so please disregard it for now.
Comment 4 Gary Benson 2005-07-04 05:16:07 EDT
I ran this on one of the beehive boxes with an empty classmap.db, so it's not a
native compilation issue:

  [root@crowe redhat]# rpm -q eclipse-ecj libgcj
  eclipse-ecj-3.1.0_fc-1
  libgcj-4.0.0-13
  [root@crowe redhat]# gcj-dbtool -l /usr/lib64/gcj-4.0.0/classmap.db
  Capacity: 0
  Size: 0

  Elements:
  [root@crowe redhat]# rpmbuild -ba SPECS/perseus-cache.spec
    ...
  + ant jar jdoc
  Buildfile: build.xml

  compile:
   [mkdir] Created dir: /usr/src/redhat/BUILD/cache/output/build
   [javac] Compiling 24 source files to /usr/src/redhat/BUILD/cache/output/build
   [javac] incorrect classpath: /usr/src/redhat/BUILD/cache/output/build:...
   [javac] incorrect classpath: /usr/src/redhat/BUILD/cache/src
   [javac] ----------
Comment 5 Gary Benson 2005-07-04 05:35:07 EDT
Created attachment 116323 [details]
Script to exercise java.util.StringTokenizer

When I put the failing classpaths through java.util.StringTokenizer, though, it
splits them perfectly:

  [root@crowe ~]# javac Test.java
  [root@crowe ~]# java Test
/usr/src/redhat/BUILD/cache/output/build:/usr/src/redhat/BUILD/cache/externals/[fractal][fractal].jar:/usr/src/redhat/BUILD/cache/externals/[monolog][ow_monolog].jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/objectweb-anttask.jar:/usr/lib/jvm/java/lib/tools.jar
/usr/src/redhat/BUILD/cache/src
  result:
  > /usr/src/redhat/BUILD/cache/output/build
  > /usr/src/redhat/BUILD/cache/externals/[fractal][fractal].jar
  > /usr/src/redhat/BUILD/cache/externals/[monolog][ow_monolog].jar
  > /usr/share/java/ant.jar
  > /usr/share/java/ant-launcher.jar
  > /usr/share/java/jaxp_parser_impl.jar
  > /usr/share/java/xml-commons-apis.jar
  > /usr/share/java/objectweb-anttask.jar
  > /usr/lib/jvm/java/lib/tools.jar
  result:
  > /usr/src/redhat/BUILD/cache/src

Oddly, the second "incorrect classpath" is just one element (and it exists) so
quite what the problem is there I don't know.
Comment 6 Gary Benson 2005-07-04 10:38:39 EDT
This is because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=92398.
Comment 8 Andrew Haley 2005-07-04 13:15:30 EDT
To be clear: it's because ecj now treats "[" and "]" as special characters.  Ths
breaks because jpackage.org uses "[" and "]" as characters in filenames.  You
can blame jpackage.org for this (and I do) but in the meantime we need to fix ecj.
Comment 9 Gary Benson 2005-07-04 13:24:38 EDT
I've committed a patch to eclipse that disables it's "[]" parsing, and Andrew
Overholt is going to build it for me overnight (my overnight, not his). 
Hopefully we'll have a working beehive again by tomorrow :)
Comment 10 Andrew Overholt 2005-07-04 21:10:32 EDT
eclipse-3.1.0_fc-2 finished.  I tried to reproduce your perseus build issue but
I'm having issues doing so :)  Hopefully you can see if things are fixed
tomorrow, Gary.
Comment 11 Gary Benson 2005-07-05 06:58:00 EDT
Yeah, perseus and everything else are building.  nanoxml isn't, but I expect
that's a separate issue so I'm closing this.
Comment 12 Gary Benson 2005-07-28 06:49:20 EDT
The nanoxml failure I mentioned originally is actually
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105430.
Comment 13 Andrew Overholt 2006-01-04 15:58:18 EST
Should we close this now, Gary?  We're still carrying the patch but I'd like to
move it upstream if that's acceptable.  Thoughts?
Comment 14 Gary Benson 2006-01-05 04:02:04 EST
Sure.  Though our patch simply disables the broken bit, whereas I expect
upstream would want it fixing properly...
Comment 15 Anthony Green 2006-07-05 20:04:26 EDT
I'm reopening this bug against rawhide.  

Did Gary's "[]" parsing patch get dropped when we upgraded to Eclipse 3.2 in
rawhide?  I'm getting "incorrect classpath" messages when I try to build things
with jpackage managed symlinks.
Comment 16 Andrew Overholt 2006-07-05 22:22:05 EDT
The patch didn't work anymore due to access restrictions now being used in 3.2.
 We made a new patch and tested it and it worked.  Can you give an example?
Comment 17 Anthony Green 2006-07-06 12:49:53 EDT
(In reply to comment #16)
> The patch didn't work anymore due to access restrictions now being used in 3.2.
>  We made a new patch and tested it and it worked.  Can you give an example?

Thanks.  Just try anything that uses "build-jar-repository".  The tomcat5 SRPM
would be a good example for instance.

I'm not sure how the [] are interpreted by Eclipse, but do you think we should
be pushing for JPackage to change their ways?
Comment 18 Andrew Overholt 2006-07-06 14:00:24 EDT
(In reply to comment #17)
> (In reply to comment #16)
> > The patch didn't work anymore due to access restrictions now being used in 3.2.
> >  We made a new patch and tested it and it worked.  Can you give an example?
> 
> Thanks.  Just try anything that uses "build-jar-repository".  The tomcat5 SRPM
> would be a good example for instance.

Hmm.  I build the Eclipse SDK with some build-jar-repository calls and it works
fine.  I'll try tomcat5 when I get 3.2 final built.

> I'm not sure how the [] are interpreted by Eclipse, but do you think we should
> be pushing for JPackage to change their ways?

We just changed the patch so that filenames that *begin* with [ are parsed as
files and not as compiler flags.  Of course, I still think that JPackage
conventions of []s are silly but I'm pretty sure that's changing with their next
"release".
> 

Comment 19 Andrew Overholt 2006-08-01 13:32:15 EDT

*** This bug has been marked as a duplicate of 199961 ***

Note You need to log in before you can comment on or make changes to this bug.