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 serviceability-dev mailing list