I came across a weird issue while trying to build rssowl. I've attached the test file. Trying this works:
ecj RSSOwlI18nZHtw.java
while this appears to hang:
ecj -encoding utf8 RSSOwlI18nZHtw.java
I can reproduce this behaviour on both an x86 box running an Eclipse 3.1 ecj (built myself) and on a ppc box running Eclipse 3.1 RC3 (the RPMs we have in rawhide). Using Sun's javac (on the x86 box) does not hang when I use "-encoding utf8". All are FC4 machines (with gcc*-4.0.0-11 in the x86 case and gcc*-4.0.0-13 in the ppc case).
To add to the bizarre-ness, this appears to be as small as I can make the test file without it being unable to reproduce the problem; I can't seem to remove any of the lines if I want to continue to reproduce. In another interesting twist, renaming the file (and class) to "TestUTF8" does not reproduce the problem.
Anyone know what's going on?
Andrew
On Tue, 2005-06-28 at 17:58 -0400, Andrew Overholt wrote:
I can reproduce this behaviour on both an x86 box running an Eclipse 3.1 ecj (built myself) and on a ppc box running Eclipse 3.1 RC3 (the RPMs we have in rawhide).
For what it's worth, I can't reproduce this on a vanilla x86 FC4 machine.
$ rpm -qf /usr/bin/ecj eclipse-ecj-3.1.0_fc-0.M6.22
Did you try breaking into the hanging process with gdb to see what it's doing?
AG
"Andrew" == Andrew Overholt overholt@redhat.com writes:
Andrew> I came across a weird issue while trying to build rssowl. Andrew> I've attached the test file. Trying this works: Andrew> ecj RSSOwlI18nZHtw.java Andrew> while this appears to hang: Andrew> ecj -encoding utf8 RSSOwlI18nZHtw.java
I can't even run ecj on my FC4 box :-( I'm using eclipse-ecj-3.1.0_fc-0.RC3.3. When I try 'ecj RSSOwlI18nZHtw.java', I see:
Exception in thread "main" java.lang.NoClassDefFoundError: while resolving class: org.eclipse.jdt.internal.compiler.batch.Main at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at org.eclipse.jdt.internal.compiler.batch.Main.main(java.lang.String[]) (/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.problem.ProblemSeverities not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) ...5 more
Andrew> To add to the bizarre-ness, this appears to be as small as I can make Andrew> the test file without it being unable to reproduce the problem; I can't Andrew> seem to remove any of the lines if I want to continue to reproduce. In Andrew> another interesting twist, renaming the file (and class) to "TestUTF8" Andrew> does not reproduce the problem. Andrew> Anyone know what's going on?
This would be consistent with some kind of buffer boundary issue -- like if some obscure charset translation failure occurs only when the triggering data appears at the boundary of an internal buffer. With a bug like this, small changes to the text would hide the failure. That's just one possible theory though.
Tom
java-devel@lists.fedoraproject.org