Comment 1 Philipe Mulet 2005-11-08 05:14:48 EST

Which Eclipse build are you using ?
Olivier - could be a good candidate for backporting to 3.1.2.

Comment 2 Olivier Thomann 2005-11-08 08:47:19 EST

I am investigating.

Comment 3 Olivier Thomann 2005-11-08 08:47:56 EST

Raise severity to blocker since this prevents the file from being compiled
without any workaround.

Comment 4 Olivier Thomann 2005-11-08 09:05:46 EST

So far I cannot reproduce. Please provide the build id.

Comment 5 Joanne Woo 2005-11-08 12:26:46 EST

I'm using the JDT compiler in Eclipse 3.1.0 (CVS tag: R3_1).  I'll try to find
out what the build id is, if you still need it.

I'll be atatching the CDT file SimpleToken.java shortly.

Sorry for not providing this info earlier and thanks for looking into this!

Comment 6 Joanne Woo 2005-11-08 12:27:58 EST

Created attachment 29549 [details]
CDT source file.

Comment 7 Olivier Thomann 2005-11-08 15:19:13 EST

I cannot reproduce with HEAD. Could you please send me all the files I need to
compile this version of the SimpleToken class.
I'll try to reproduce with an older version.

Comment 8 Olivier Thomann 2005-11-08 15:30:39 EST

Reducing severity since I cannot reproduce with 3.1 maintenance HEAD stream,
current 3.2 HEAD and 3.0 maintenance HEAD stream.
I definitely need all dependant source files.
I'll try to get all source files from CDT 3.0.0 out of CVS.

Comment 9 Olivier Thomann 2005-11-08 15:35:11 EST

I got all source tagged as CDT_3_0 and I still could not reproduce.

Comment 10 Joanne Woo 2005-11-08 15:41:04 EST

Olivier, did you test this in the workbench?   The failure we're seeing is when
building outside the workbench, in the command-line.  We need to be able to do
this.  Does the JDT compiler require any special options to be set?

Comment 11 Olivier Thomann 2005-11-08 18:28:11 EST

I tried in the workbench and on the command line. I could not reproduce.
Could you please provide the exact same set of source files that you are using?
Also give me the command line and all possible details in order to reproduce the
problem.
Thanks for your help.

Comment 12 Joanne Woo 2005-11-08 18:39:48 EST

Sure, I'll attach what I think you'll need shortly.  BTW, I'm sorry for not
pointing out that I was building in batch mode at the very beginning.  Thanks
for your patience! 

Comment 13 Joanne Woo 2005-11-08 19:34:32 EST

Created attachment 29577 [details]
ecj.jar and build.xml for cdt.core

Comment 14 Olivier Thomann 2005-11-08 19:50:44 EST

I could not reproduce the problem.
Can you reproduce it all the time?
If yes, could you please provide the source files you are compiling?

Comment 15 Joanne Woo 2005-11-08 20:01:08 EST

I think the only file is different is the build.xml file for
org.eclipse.cdt.core.  The one I'm using is attached.  I also provided ecj.jar,
in it's different.

I'm using the same version of Ant as in Eclipse 3.1.0, i.e. version 1.6.5.

The command line used to kick off the CDT build is as follows:
rc=0 ; \
JAVA_HOME=/opt/montavista/common/jdk/jre \
ANT_HOME=/opt/montavista/common/apache-ant \
CLASSPATH=/home/build/SOURCES/ecj.jar \
/opt/montavista/common/apache-ant/bin/ant \
    -buildfile `/home/build/SOURCES/cygpath -w
/home/build/BUILD/common-devrocket-2.1.0/build/tools/build.xml` \
    -Dos=linux \
    -Dws=gtk \
    -Darch=x86 \
    -Dbasedir=`/home/build/SOURCES/cygpath -w
/home/build/BUILD/common-devrocket-2.1.0/` \
    -Dbootclasspath=`/home/build/SOURCES/cygpath -wp
/opt/montavista/common/jdk/jre/lib/rt.jar:/opt/montavista/common/jdk/jre/lib/jsse.jar`
\
    -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter \
    -DjavacDebugInfo=off \
    -DjavacFailOnError=false \
    -DjavacSource=1.4 \
    -DjavacTarget=1.4 \
    -DjavacVerbose=false \
    init compile ; \
[ $rc -eq 0 ] || exit $rc
Buildfile: /home/build/BUILD/common-devrocket-2.1.0/build/tools/build.xml


I'll also attach /home/build/BUILD/common-devrocket-2.1.0/build/tools/build.xml
in case its of any help.  It's a top-level build file to launch the build of the
various CDT plugins.

The CDT source is the same as CDT 3.0.0.

Comment 16 Joanne Woo 2005-11-08 20:01:59 EST

Created attachment 29578 [details]
top-level tools build.xml

Comment 17 Joanne Woo 2005-11-08 20:04:02 EST

Yes, the failure occurs consistently for me.   How did you build in the command
line?  Perhaps I should build the way you did to make this work.

Comment 18 Joanne Woo 2005-11-08 20:31:20 EST

Created attachment 29579 [details]
org.eclipse.cdt.core source from CDT 3.0.0

Comment 19 Joanne Woo 2005-11-08 20:34:28 EST

I've attached the source for the org.eclipse.cdt.core plugin.  You may find
changes which my team has made (there may not be any) but SimpleToken.java was
definitely not changed.

Please let me know if you need anything else from me.

Comment 20 Olivier Thomann 2005-11-08 21:13:33 EST

Thank you. I will continue to investigate this issue. Hopefully I will be able
to reproduce the failure.

Comment 21 Olivier Thomann 2005-11-09 09:44:22 EST

I could not reproduce it. I don't know what I am doing that could be different
from your settings.
Did you try with 3.1.1 to see if this problem is fixed?
I used the jar file of JDT/Core plugin from the 3.1 build. I used your source
file and the build.xml located in the project folder. The build is successful.
Could you please try to run using the following compiler arg:
<compilerarg line="${temp.folder}/cdtcorelog.xml"/>
And send me the log file. I'd like to know what files are compiled during your
compilation.
If this doesn't work, I can try to send you a patch based on 3.1.1 that could
fix this issue. I simply wanted to understand how the failure occured.
Thanks for your help tracking down this issue.

Comment 22 Olivier Thomann 2005-11-09 10:41:29 EST

I got it.
Don't know why suddenly I could reproduce it, but this is the case.
I am working on a fix.

Comment 23 Olivier Thomann 2005-11-09 12:10:13 EST

I could not reproduce because in my testing I was generating the debug
attributes. To reproduce the failures, the debug attributes must not be generated.
Fixed and released in HEAD.
Regression test added in
org.eclipse.jdt.core.tests.compiler.regression.XLargeTest.test008

Comment 24 Olivier Thomann 2005-11-09 12:28:25 EST

Backported to 3.1 maintenance and 3.0 maintenance streams.
Same regression test added in both streams

Comment 25 Joanne Woo 2005-11-09 12:34:22 EST

Thanks very much for getting this fixed so quickly, Olivier!  Would you please
attach the patch to this bug so that I can apply it to our source repository?

Comment 26 Joanne Woo 2005-11-09 12:40:45 EST

Olivier, do you know why the exception is not thrown when building in the
workbench?  Is it because the debug attributes are generated when building in
the workbench?

Comment 27 Olivier Thomann 2005-11-09 12:42:00 EST

Yes, if you have debug attribute the situation described below won't happen.

The fix is very simple.
Replace the resizeByteArray() method in
org.eclipse.jdt.internal.compiler.codegen.CodeStream with:
private final void resizeByteArray() {
	int length = bCodeStream.length;
	int requiredSize = length + length;
	if (classFileOffset >= requiredSize) {
		// must be sure to grow enough
		requiredSize = classFileOffset + length;
	}
	System.arraycopy(bCodeStream, 0, bCodeStream = new byte[requiredSize], 0, length);
}

Note the >= instead of >.
In your case the byte array size was 400 and the classFileOffset was 800.
So the resize checked wrongly (using >) that doubling the size was sufficient.
So after the resize, the byte array size is 800 and the classFileOffset is still
800. So writing at index 800 in an array of 800 elements leads to the exception
you got.
By checking >=, we will then resize the byte array to 1200 and there is enough
space to put what needs to be added.
Let me know if you could patch it successfully. Next 3.1.2 build or
integration/nightly build will contain the fix.

Comment 28 Joanne Woo 2005-11-09 12:50:46 EST

I see.  What a difference ">=" makes.  :-)

Are debug attributes not generated when the build is done in batch mode?  What's
the option to turn this on and off?

Comment 29 Olivier Thomann 2005-11-09 12:56:55 EST

I think this is an ant feature.
In the script you send me, I can see:
	<property name="javacDebugInfo" value="on"/>
And in the javac task, you have:
debug="${javacDebugInfo}"

But it seems that this is overriden when properties are passed on the command
line. And your command line contains:
    -DjavacDebugInfo=off \

So no debug attributes are generated. By default in the workbench, line number
attribute and source attribute are generated. This is configurable in the
compiler preferences per project or for the whole workbench.

Comment 30 Joanne Woo 2005-11-09 13:10:10 EST

I understand now.  I'll test the fix and update this bug shortly.   Thanks for
all your help, Olivier!

Comment 31 Joanne Woo 2005-11-09 23:11:10 EST

Fix verified with CDT 3.0.0 source.

Comment 32 Olivier Thomann 2005-11-10 09:22:23 EST

Reopen to close as FIXED.
We will verify it again prior to 3.2M4. Thanks for annotating it.

Comment 33 Olivier Thomann 2005-11-10 09:22:34 EST

Fixed.

Comment 34 Frederic Fusier 2005-12-12 11:10:41 EST

Verified for 3.2 M4 using build I20051212-0010

Comment 35 Frederic Fusier 2006-01-09 06:45:27 EST

Reopen for 3.1.2 verification

Comment 36 Frederic Fusier 2006-01-09 06:46:37 EST

We also need to verify that's this bug fix is in R3_1_maintenance stream as well before 3.1.2 delivery...

Comment 37 Maxime Daniel 2006-01-10 05:09:34 EST

Verified for 3.1.2 using build M20060109-1200.

Comment 38 Frederic Fusier 2006-01-10 05:25:20 EST

Verified for 3.1.2 using build M20060109-1200 (maxime)