You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ilya Berezhniuk (JIRA)" <ji...@apache.org> on 2007/12/27 01:13:43 UTC
[jira] Commented: (HARMONY-5304) [drlvm][gc_gen] assert in
ClassCastTest from the reliability test suite
[ https://issues.apache.org/jira/browse/HARMONY-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554497 ]
Ilya Berezhniuk commented on HARMONY-5304:
------------------------------------------
Last commit related to uncompressed references implementation was r600979 commit (lockword offset in magics).
So currently uncompressed references implementation includes 4 commits: r599482, r599491, r599519, r600979.
To check if uncompressed references commits introduce this bug, I've got r599465 and applied all these 4 patches.
The result confirms Pavel's conclusion - assertion occures with all these patches applied.
Now I'm trying to investigate this bug closer.
I'm going to patching the code to make obj_info offset 4-byte again, to ensure that the cause is in 64-bit obj_info operations, not in changed obj_info offset.
BTW, I've also started this test on latest VM revision (including last GC_GEN commit r606876) - the test crashes every run now, with 3 different assertions:
1) thread_native_thin_monitor.c:385: hythread_thin_monitor_try_enter: Assertion `!(0==(*lockword_ptr & ((1<<10))))' failed
2) Prepare.cpp:1143: bool Class::prepare(Global_Env*): Assertion `m_state == ST_BytecodesVerified' failed
3) thread_native_thin_monitor.c:665: hythread_inflate_lock: Assertion `hythread_owns_thin_lock(tm_self_tls, lockword)' failed
> [drlvm][gc_gen] assert in ClassCastTest from the reliability test suite
> -----------------------------------------------------------------------
>
> Key: HARMONY-5304
> URL: https://issues.apache.org/jira/browse/HARMONY-5304
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Linux x86_64
> Reporter: Andrey Yakushev
>
> vm.classloading.ClassCastTest failed on cruise control:
> http://people.apache.org/~smishura/r602572/Linux_x86_64/reliability/vm/classloading/53_ClassCastTest.html
> I tried the debug version of DRLVM and obtained assert:
> java: /nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/thread/src/thread_native_thin_monitor.c:665: hythread_inflate_lock: Assertion `hythread_owns_thin_lock(tm_self_tls, lockword)' failed.
> SIGABRT in VM code.
> Stack trace:
> 0: raise (??:-1)
> 1: abort (??:-1)
> 2: ?? (??:-1)
> 3: ?? (??:-1)
> 4: ?? (??:-1)
> 5: ?? (??:-1)
> 6: __fxprintf (??:-1)
> 7: asprintf (??:-1)
> 8: ?? (??:-1)
> 9: ?? (??:-1)
> 10: ?? (??:-1)
> 11: __assert_fail (??:-1)
> 12: ?? (??:-1)
> 13: ?? (??:-1)
> 14: ?? (??:-1)
> 15: ?? (??:-1)
> 16: hythread_inflate_lock (/nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/thread/src/thread_native_thin_monitor.c:666)
> 17: ManagedObject::get_obj_info_addr() (/nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/vmcore/include/object_layout.h:256)
> 18: ?? (??:-1)
> 19: java/lang/Class.initReflectionData()V (Class.java:748)
> 20: java/lang/Class.getName()Ljava/lang/String; (Class.java:515)
> 21: org/apache/harmony/test/reliability/vm/classloading/ClassCastTest.testContent(Ljava/lang/Class;)V (ClassCastTest.java:129)
> 22: org/apache/harmony/test/reliability/share/ClassMultiTestBase.run()V (ClassMultiTestBase.java:100)
> 23: java/lang/Thread.run()V (Thread.java:657)
> 24: java/lang/Thread.runImpl()V (Thread.java:668)
> LTend of stack traceGT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (HARMONY-5304) [drlvm][gc_gen] assert in ClassCastTest from the reliability test suite
Posted by Xiao-Feng Li <xi...@gmail.com>.
Ilya, based on your descriptions about the new failures in lockword,
it looks like the failures are indeed related with object header
processing. I suggest you just use the latest SVN for the
investigation if it hits assertion definitely.
In the latest SVN, please check lines 157 ~ 197 in
working_vm\vm\gc_gen\src\common\gc_block.h. The functions there
store/load a native pointer into/from obj_info. This is the only place
(in my understanding) changed in latest SVN that is related to object
header layout. And you can check the code before this change to
confirm if they will hit different assertions.
Would you let me know the process and exact commands and options to
reproduce the failure?
Thanks,
xiaofeng
On Dec 27, 2007 8:13 AM, Ilya Berezhniuk (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/HARMONY-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554497 ]
>
> Ilya Berezhniuk commented on HARMONY-5304:
> ------------------------------------------
>
> Last commit related to uncompressed references implementation was r600979 commit (lockword offset in magics).
> So currently uncompressed references implementation includes 4 commits: r599482, r599491, r599519, r600979.
>
> To check if uncompressed references commits introduce this bug, I've got r599465 and applied all these 4 patches.
> The result confirms Pavel's conclusion - assertion occures with all these patches applied.
>
> Now I'm trying to investigate this bug closer.
> I'm going to patching the code to make obj_info offset 4-byte again, to ensure that the cause is in 64-bit obj_info operations, not in changed obj_info offset.
>
>
> BTW, I've also started this test on latest VM revision (including last GC_GEN commit r606876) - the test crashes every run now, with 3 different assertions:
> 1) thread_native_thin_monitor.c:385: hythread_thin_monitor_try_enter: Assertion `!(0==(*lockword_ptr & ((1<<10))))' failed
> 2) Prepare.cpp:1143: bool Class::prepare(Global_Env*): Assertion `m_state == ST_BytecodesVerified' failed
> 3) thread_native_thin_monitor.c:665: hythread_inflate_lock: Assertion `hythread_owns_thin_lock(tm_self_tls, lockword)' failed
>
>
>
> > [drlvm][gc_gen] assert in ClassCastTest from the reliability test suite
> > -----------------------------------------------------------------------
> >
> > Key: HARMONY-5304
> > URL: https://issues.apache.org/jira/browse/HARMONY-5304
> > Project: Harmony
> > Issue Type: Bug
> > Components: DRLVM
> > Environment: Linux x86_64
> > Reporter: Andrey Yakushev
> >
> > vm.classloading.ClassCastTest failed on cruise control:
> > http://people.apache.org/~smishura/r602572/Linux_x86_64/reliability/vm/classloading/53_ClassCastTest.html
> > I tried the debug version of DRLVM and obtained assert:
> > java: /nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/thread/src/thread_native_thin_monitor.c:665: hythread_inflate_lock: Assertion `hythread_owns_thin_lock(tm_self_tls, lockword)' failed.
> > SIGABRT in VM code.
> > Stack trace:
> > 0: raise (??:-1)
> > 1: abort (??:-1)
> > 2: ?? (??:-1)
> > 3: ?? (??:-1)
> > 4: ?? (??:-1)
> > 5: ?? (??:-1)
> > 6: __fxprintf (??:-1)
> > 7: asprintf (??:-1)
> > 8: ?? (??:-1)
> > 9: ?? (??:-1)
> > 10: ?? (??:-1)
> > 11: __assert_fail (??:-1)
> > 12: ?? (??:-1)
> > 13: ?? (??:-1)
> > 14: ?? (??:-1)
> > 15: ?? (??:-1)
> > 16: hythread_inflate_lock (/nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/thread/src/thread_native_thin_monitor.c:666)
> > 17: ManagedObject::get_obj_info_addr() (/nfs/ims/proj/drl/mrt3/users/avyakush/ws/bt_l64/build/checkouts/drlvm/vm/vmcore/include/object_layout.h:256)
> > 18: ?? (??:-1)
> > 19: java/lang/Class.initReflectionData()V (Class.java:748)
> > 20: java/lang/Class.getName()Ljava/lang/String; (Class.java:515)
> > 21: org/apache/harmony/test/reliability/vm/classloading/ClassCastTest.testContent(Ljava/lang/Class;)V (ClassCastTest.java:129)
> > 22: org/apache/harmony/test/reliability/share/ClassMultiTestBase.run()V (ClassMultiTestBase.java:100)
> > 23: java/lang/Thread.run()V (Thread.java:657)
> > 24: java/lang/Thread.runImpl()V (Thread.java:668)
> > LTend of stack traceGT
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
http://xiao-feng.blogspot.com