Invalid JCK test case gcpl00104.c
Yuri Gaevsky
Yuri.Gaevsky at Sun.COM
Tue Nov 11 12:06:49 PST 2008
Martin,
It is on the exclude list - please load updated one.
Thanks,
-Yuri
Alan Bateman wrote:
> Martin,
>
> Yuri can confirm but I suspect this one has already been fixed as:
> 6710561: JCK6b:
> vm/jvmti/GetConstantPool/gcpl001/gcpl00104/gcpl00104.html can fail under
> JDK 6.0 on Linux
> but not sure why it is not on the exclude list.
>
> -Alan.
>
>
> Martin Buchholz wrote:
>> Executive summary: Invalid test case; please file a JCK bug and add to
>> the JCK exclude list.
>>
>> Whiile running the JCK,
>> we had random crashes due to memory corruption in the JCK test
>> JCK-runtime-6b/tests/vm/jvmti/GetConstantPool/gcpl001/gcpl00104/gcpl00104.c
>>
>>
>> The test suffers from multiple memory corruption bugs.
>>
>> E.g. in this piece of code
>>
>> size = 5;
>> .....
>> cp_info = (gcpl00104_Integer_info*)
>> malloc(sizeof(gcpl00104_Integer_info));
>> if (cp_info != NULL) {
>> cp_info->tag = cp_bytes[*offset];
>> lprintf(env, "0x");
>> for (i = 1; i < size; i++) {
>> cp_info->bytes[i] = cp_bytes[*offset + i];
>> lprintf(env, "%0*X", 2, (int) cp_info->bytes[i]);
>> }
>>
>> the test case is writing to cp_info->bytes[4],
>> but bytes is of type char[4], so that's (possibly)
>> one past the end of the malloc'ed region.
>>
>> Other functions in this test have similar bugs.
>>
>> Whether you actually see a crash is strongly dependent on your malloc
>> implementation.
>> valgrind was able to pinpoint the cause; to valgrindise the JDK, you
>> need the flag
>> --trace-children
>>
>> Thanks,
>>
>> Martin
>>
>
More information about the conformance-discuss
mailing list