From martinrb at google.com  Tue Nov 11 11:45:52 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Nov 2008 11:45:52 -0800
Subject: Invalid JCK test case gcpl00104.c
Message-ID: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>

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


From Yuri.Gaevsky at Sun.COM  Tue Nov 11 12:02:24 2008
From: Yuri.Gaevsky at Sun.COM (Yuri Gaevsky)
Date: Tue, 11 Nov 2008 12:02:24 -0800
Subject: Invalid JCK test case gcpl00104.c
In-Reply-To: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
References: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
Message-ID: <4919E4D0.5030900@Sun.com>

Hi, Martin.

Several months ago we excluded this test from JCK6b due to reasons you've described.

Thanks,
-Yuri

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


From martinrb at google.com  Tue Nov 11 12:03:28 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Nov 2008 12:03:28 -0800
Subject: Invalid JCK test case gcpl00104.c
In-Reply-To: <4919E4D0.5030900@Sun.com>
References: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
	<4919E4D0.5030900@Sun.com>
Message-ID: <1ccfd1c10811111203q34a3ddaft21a6e30c1819cef5@mail.gmail.com>

Thanks!

Martin

On Tue, Nov 11, 2008 at 12:02, Yuri Gaevsky <Yuri.Gaevsky at sun.com> wrote:
> Hi, Martin.
>
> Several months ago we excluded this test from JCK6b due to reasons you've
> described.
>
> Thanks,
> -Yuri
>
> 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
>


From Yuri.Gaevsky at Sun.COM  Tue Nov 11 12:06:49 2008
From: Yuri.Gaevsky at Sun.COM (Yuri Gaevsky)
Date: Tue, 11 Nov 2008 12:06:49 -0800
Subject: Invalid JCK test case gcpl00104.c
In-Reply-To: <4919E47A.3050101@sun.com>
References: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
	<4919E47A.3050101@sun.com>
Message-ID: <4919E5D9.7090100@Sun.com>

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
>>   
> 


From Alan.Bateman at Sun.COM  Tue Nov 11 12:00:58 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 11 Nov 2008 20:00:58 +0000
Subject: Invalid JCK test case gcpl00104.c
In-Reply-To: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
References: <1ccfd1c10811111145k51356ad4t5112fa556732cf02@mail.gmail.com>
Message-ID: <4919E47A.3050101@sun.com>

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
>