Message from Sequent:

> From: ###@###.###
> Date: Wed, 7 Oct 1998 11:37:55 -0700
> To: ###@###.######@###.######@###.###
> Subject: JCK-116a test problems
>
> I believe following two tests in JCK-116a are incorrect which can cause
> the VM to terminate with a SEGV on some systems.
>
> execution00414 - special class representation error for the provoking
> of the exception
> execution00415 - special class representation error for the provoking
> of the exception
>
> The class files (execution00414a.class and execution00415a.class) contain
> constant_pool_count values that allow for only one instead of two entries
> for the double and long constants in the constant_pool tables. Allowing
> for the double and long entries the constant_pool_count in each class file
> should be 26 instead of 25.
>
> The incorrect constant_pool_count values cause LoadConstantPool() in
> src/share/java/runtime/classloader.c to allocate 4 bytes less memory
> for the constant_pool buffer than required. When the final 8 byte
> long or double entry value is written to the buffer 4 bytes of the
> value trash data (in our case a pointer that later causes a SEGV)
> beyond the end of the buffer.
>
> Please provide a corrected test or revised exclude list as soon as
> possible. This is urgent since it could delay our release of 1.1.6.
>

===============================================================

Message from Corel:

>
> > Date: Tue, 29 Sep 1998 13:37:59 -0400
> > From: "Andy Bounsall" <###@###.###>
> > MIME-Version: 1.0
> > To: ###@###.###
> > Subject: JCK-116a problems
> > Content-Transfer-Encoding: 7bit
> >
> > Corel Computer is a JAE licensee and we have ported the Sun 1.1.x JRE to
> > run on our StrongARM Linux based NetWinder computer. Having applied the
> > 1.1.6 changes to our port, we ran through the JCK-116a suite on our
> > NetWinder port, using a Sun Ultra 2 running Solaris 2.6 as a control.
> > During this testing I believe I have discovered 2 tests in the JCK-116a
> > suite which are in error.
> >
> > The particular tests are
> > javasoft.sqe.tests.vm.concepts.execution004.execution00414.execution00414
> > and
> > javasoft.sqe.tests.vm.concepts.execution004.execution00415.execution00415.
> > In both cases, the tests are checking for the JVMs ability to reject a
> > class file which has a bad index value. However the value of
> > constant_pool_count in the ...execution00414a and ...execution00415a
> > class files is incorrect. It returns a count of 25. The code in
> > LoadConstantPool() in classloader.c allocates a block big enough to hold
> > an array of 25 elements. Ignoring the reserved first element, this
> > leaves space for 24 items in the constant_pool. However, in both cases
> > the 24th item in the constant pool is a 64 bit type (int64_t for 00414a
> > and double for 00415a). The VM code blindly assigns values to the next 2
> > elements of the array (i.e. at index 24 and 25) via the SET_INT_64()
> > macro, writing past the end of the allocated memory. Later, when the
> > intended corruption of the class file is detected within the
> > InitializeStaticVar() function and the memory blocks allocated for this
> > class are freed, the memory overwrite causes a segmentation violation on
> > our machine and the VM crashes.
> >
> > After looking at this, I'm at a bit of a loss to understand why these
> > tests do not fail on the Sun Ultra. The only reason I can imagine is
> > that due to memory management or alignment differences on the Ultra, the
> > block of memory which is allocated may actually be larger than what was
> > requested so the overwrite is undetected, or the memory into which the
> > overwrite occurs may not be otherwise used. In either case, I have to
> > assume that the overwrite is occurring, but going undetected.
> >
> > Could you please confirm my suspicions that these 2 tests are actually
> > in error and advise me of your findings.
> >
> > Thanks,
> > Andy <###@###.###>
> >


------------- End Forwarded Message -------------