You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Petrashkova, Vera Y" <ve...@intel.com> on 2007/05/07 16:26:39 UTC
[drlvm] VM crashes on 3 tests from DRLVM Validation test suite
3 tests from DRLVM Validation test suite
(http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
r535615 Windows2003 ia32 while passed since r531398.
1) The following jvmti tests
vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
1
vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
failed because VM crashes on jvmti methods
IterateOverHeap(jvmtiEnv* env,
jvmtiHeapObjectFilter object_filter,
jvmtiHeapObjectCallback heap_object_callback,
void* user_data)
IterateOverInstancesOfClass(jvmtiEnv* env,
jclass klass,
jvmtiHeapObjectFilter object_filter,
jvmtiHeapObjectCallback heap_object_callback,
void* user_data)
when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED or
JVMTI_HEAP_OBJECT_EITHER
VM works correctly when object_filter equals to
JVMTI_HEAP_OBJECT_TAGGED.
2) VM also crashes on the following test which creates large array
vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
ray0901
It is occurred on Windows 2003 but this test passes on Windows XP.
These failures may be intermittent because the listed tests failed on
DRLVM r531398 but they passed on the next builds till r535615.
Thank you,
Vera Petrashkova
Re: [drlvm] VM crashes on 3 tests from DRLVM Validation test suite
Posted by chunrong lai <ch...@gmail.com>.
Thanks. *HARMONY-3860* <https://issues.apache.org/jira/browse/HARMONY-3860> was
created for that.
One small issue is that GCv5 supports heap iteration which GCv4.1 does not.
On 5/14/07, Gregory Shimansky <gs...@apache.org> wrote:
>
> chunrong lai wrote:
> > I just checked the IterateOverHeap/IterateInstances issue. I found
> the
> > problem is not in GCv5 but in the tag setting of the JVMTI environment.
> > In my experiments there is assertion failure in
> > assert(global_ti_env->tags) at vm_iterate_object(), which probably means
> no
> > tag setting before gc_iterate_heap().
> >
> > GCv4.1 has not this problem because it initializes the
> > jvmti_heap_iteration as false, which means the heap is not iterated, so
> no
> > vm_iterate_ovject() is called, even if JVMTI environment askes it to do.
> > Instead I did not see GCv5 has internal problem in gc_iterate_heap().
> >
> > So I am also looking for your suggestion for below options (1) Set
> > jvmti_heap_iteration of GCv5 with false as GCv4.1. (2) Discard the
> > assertion
> > in vm_iterate_object. (3) Rewrite the test case to set tag before
> > gc_iterate_heap().
>
> Hello Chunrong, could you please file a JIRA on this problem for
> tracking purposes? It seems that there is a bug in VM which cannot
> correctly handle GC that don't support heap iteration. We shouldn't
> forget to fix it.
>
> > On 5/8/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >>
> >> They might be caused by recent switch of the GC to GCv5. Will check,
> >> thanks.
> >>
> >> xiaofeng
> >>
> >> On 5/7/07, Petrashkova, Vera Y <ve...@intel.com> wrote:
> >> > 3 tests from DRLVM Validation test suite
> >> > (http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
> >> > r535615 Windows2003 ia32 while passed since r531398.
> >> >
> >> >
> >> >
> >> > 1) The following jvmti tests
> >> >
> >> >
> >> >
> >>
> vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
> >> > 1
> >> >
> >> >
> >> >
> vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
> >> >
> >> >
> >> >
> >> > failed because VM crashes on jvmti methods
> >> >
> >> >
> >> >
> >> > IterateOverHeap(jvmtiEnv* env,
> >> > jvmtiHeapObjectFilter object_filter,
> >> > jvmtiHeapObjectCallback heap_object_callback,
> >> >
> >> > void* user_data)
> >> >
> >> > IterateOverInstancesOfClass(jvmtiEnv* env,
> >> > jclass klass,
> >> > jvmtiHeapObjectFilter object_filter,
> >> > jvmtiHeapObjectCallback heap_object_callback,
> >> >
> >> > void* user_data)
> >> >
> >> >
> >> >
> >> > when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED
> or
> >> > JVMTI_HEAP_OBJECT_EITHER
> >> >
> >> >
> >> >
> >> > VM works correctly when object_filter equals to
> >> > JVMTI_HEAP_OBJECT_TAGGED.
> >> >
> >> >
> >> >
> >> > 2) VM also crashes on the following test which creates large array
> >> >
> >> >
> >> >
> >>
> vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
> >> > ray0901
> >> >
> >> >
> >> >
> >> > It is occurred on Windows 2003 but this test passes on Windows XP.
> >> >
> >> >
> >> >
> >> > These failures may be intermittent because the listed tests failed on
> >> > DRLVM r531398 but they passed on the next builds till r535615.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Thank you,
> >> >
> >> > Vera Petrashkova
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> http://xiao-feng.blogspot.com
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] VM crashes on 3 tests from DRLVM Validation test suite
Posted by Gregory Shimansky <gs...@apache.org>.
chunrong lai wrote:
> I just checked the IterateOverHeap/IterateInstances issue. I found the
> problem is not in GCv5 but in the tag setting of the JVMTI environment.
> In my experiments there is assertion failure in
> assert(global_ti_env->tags) at vm_iterate_object(), which probably means no
> tag setting before gc_iterate_heap().
>
> GCv4.1 has not this problem because it initializes the
> jvmti_heap_iteration as false, which means the heap is not iterated, so no
> vm_iterate_ovject() is called, even if JVMTI environment askes it to do.
> Instead I did not see GCv5 has internal problem in gc_iterate_heap().
>
> So I am also looking for your suggestion for below options (1) Set
> jvmti_heap_iteration of GCv5 with false as GCv4.1. (2) Discard the
> assertion
> in vm_iterate_object. (3) Rewrite the test case to set tag before
> gc_iterate_heap().
Hello Chunrong, could you please file a JIRA on this problem for
tracking purposes? It seems that there is a bug in VM which cannot
correctly handle GC that don't support heap iteration. We shouldn't
forget to fix it.
> On 5/8/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>>
>> They might be caused by recent switch of the GC to GCv5. Will check,
>> thanks.
>>
>> xiaofeng
>>
>> On 5/7/07, Petrashkova, Vera Y <ve...@intel.com> wrote:
>> > 3 tests from DRLVM Validation test suite
>> > (http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
>> > r535615 Windows2003 ia32 while passed since r531398.
>> >
>> >
>> >
>> > 1) The following jvmti tests
>> >
>> >
>> >
>> vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
>> > 1
>> >
>> >
>> > vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
>> >
>> >
>> >
>> > failed because VM crashes on jvmti methods
>> >
>> >
>> >
>> > IterateOverHeap(jvmtiEnv* env,
>> > jvmtiHeapObjectFilter object_filter,
>> > jvmtiHeapObjectCallback heap_object_callback,
>> >
>> > void* user_data)
>> >
>> > IterateOverInstancesOfClass(jvmtiEnv* env,
>> > jclass klass,
>> > jvmtiHeapObjectFilter object_filter,
>> > jvmtiHeapObjectCallback heap_object_callback,
>> >
>> > void* user_data)
>> >
>> >
>> >
>> > when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED or
>> > JVMTI_HEAP_OBJECT_EITHER
>> >
>> >
>> >
>> > VM works correctly when object_filter equals to
>> > JVMTI_HEAP_OBJECT_TAGGED.
>> >
>> >
>> >
>> > 2) VM also crashes on the following test which creates large array
>> >
>> >
>> >
>> vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
>> > ray0901
>> >
>> >
>> >
>> > It is occurred on Windows 2003 but this test passes on Windows XP.
>> >
>> >
>> >
>> > These failures may be intermittent because the listed tests failed on
>> > DRLVM r531398 but they passed on the next builds till r535615.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Thank you,
>> >
>> > Vera Petrashkova
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> http://xiao-feng.blogspot.com
>>
>
--
Gregory
Re: [drlvm] VM crashes on 3 tests from DRLVM Validation test suite
Posted by chunrong lai <ch...@gmail.com>.
I just checked the IterateOverHeap/IterateInstances issue. I found the
problem is not in GCv5 but in the tag setting of the JVMTI environment.
In my experiments there is assertion failure in
assert(global_ti_env->tags) at vm_iterate_object(), which probably means no
tag setting before gc_iterate_heap().
GCv4.1 has not this problem because it initializes the
jvmti_heap_iteration as false, which means the heap is not iterated, so no
vm_iterate_ovject() is called, even if JVMTI environment askes it to do.
Instead I did not see GCv5 has internal problem in gc_iterate_heap().
So I am also looking for your suggestion for below options (1) Set
jvmti_heap_iteration of GCv5 with false as GCv4.1. (2) Discard the assertion
in vm_iterate_object. (3) Rewrite the test case to set tag before
gc_iterate_heap().
-regards,
chunrong
On 5/8/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> They might be caused by recent switch of the GC to GCv5. Will check,
> thanks.
>
> xiaofeng
>
> On 5/7/07, Petrashkova, Vera Y <ve...@intel.com> wrote:
> > 3 tests from DRLVM Validation test suite
> > (http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
> > r535615 Windows2003 ia32 while passed since r531398.
> >
> >
> >
> > 1) The following jvmti tests
> >
> >
> > vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
> > 1
> >
> >
> > vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
> >
> >
> >
> > failed because VM crashes on jvmti methods
> >
> >
> >
> > IterateOverHeap(jvmtiEnv* env,
> > jvmtiHeapObjectFilter object_filter,
> > jvmtiHeapObjectCallback heap_object_callback,
> >
> > void* user_data)
> >
> > IterateOverInstancesOfClass(jvmtiEnv* env,
> > jclass klass,
> > jvmtiHeapObjectFilter object_filter,
> > jvmtiHeapObjectCallback heap_object_callback,
> >
> > void* user_data)
> >
> >
> >
> > when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED or
> > JVMTI_HEAP_OBJECT_EITHER
> >
> >
> >
> > VM works correctly when object_filter equals to
> > JVMTI_HEAP_OBJECT_TAGGED.
> >
> >
> >
> > 2) VM also crashes on the following test which creates large array
> >
> >
> > vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
> > ray0901
> >
> >
> >
> > It is occurred on Windows 2003 but this test passes on Windows XP.
> >
> >
> >
> > These failures may be intermittent because the listed tests failed on
> > DRLVM r531398 but they passed on the next builds till r535615.
> >
> >
> >
> >
> >
> >
> >
> > Thank you,
> >
> > Vera Petrashkova
> >
> >
> >
> >
> >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [drlvm] VM crashes on 3 tests from DRLVM Validation test suite
Posted by Xiao-Feng Li <xi...@gmail.com>.
They might be caused by recent switch of the GC to GCv5. Will check, thanks.
xiaofeng
On 5/7/07, Petrashkova, Vera Y <ve...@intel.com> wrote:
> 3 tests from DRLVM Validation test suite
> (http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
> r535615 Windows2003 ia32 while passed since r531398.
>
>
>
> 1) The following jvmti tests
>
>
> vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
> 1
>
>
> vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
>
>
>
> failed because VM crashes on jvmti methods
>
>
>
> IterateOverHeap(jvmtiEnv* env,
> jvmtiHeapObjectFilter object_filter,
> jvmtiHeapObjectCallback heap_object_callback,
>
> void* user_data)
>
> IterateOverInstancesOfClass(jvmtiEnv* env,
> jclass klass,
> jvmtiHeapObjectFilter object_filter,
> jvmtiHeapObjectCallback heap_object_callback,
>
> void* user_data)
>
>
>
> when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED or
> JVMTI_HEAP_OBJECT_EITHER
>
>
>
> VM works correctly when object_filter equals to
> JVMTI_HEAP_OBJECT_TAGGED.
>
>
>
> 2) VM also crashes on the following test which creates large array
>
>
> vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
> ray0901
>
>
>
> It is occurred on Windows 2003 but this test passes on Windows XP.
>
>
>
> These failures may be intermittent because the listed tests failed on
> DRLVM r531398 but they passed on the next builds till r535615.
>
>
>
>
>
>
>
> Thank you,
>
> Vera Petrashkova
>
>
>
>
>
>
--
http://xiao-feng.blogspot.com