harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm][x86_64] status update
Date Fri, 17 Nov 2006 16:31:25 GMT
On 11/17/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> Yah, I get failed status too.  Because the VM segfaults.  Try running
> StackTest via
>
>      ./java StackTest
>
> and what do you see?  Oh, reading more...


It's output on my SuSEs
befor my changes:

$ (./build/lnx_em64t_gcc_debug/deploy/jre/bin/java -cp
./build/lnx_em64t_gcc_debug/semis/vm/em/_smoke.tests/c
Segmentation fault
$ (unset JAVA_HOME; ./build/lnx_em64t_gcc_debug/deploy/jre/bin/java -cp
./build/lnx_em64t_gcc_debug/semis/vm/
$

after em64t fix implementation.

$ (./build/lnx_em64t_gcc_debug/deploy/jre/bin/java -cp
./build/lnx_em64t_gcc_debug/semis/vm/em/_smoke.tests/c
Segmentation fault
$ (unset JAVA_HOME; ./build/lnx_em64t_gcc_debug/deploy/jre/bin/java -cp
./build/lnx_em64t_gcc_debug/semis/vm/
PASS : java.lang.StackOverflowError
$



> Can you explain that fix?



Yes, of cause... partially :)

1) mprotect can't work on main application thread without mmap. Rana found
out this fact. I think I can explain it, but it is guess only. I can't find
description of it in google... Also on different versions of Linux behavior
is different.

2) Rana implemented call of mmap for protected page to call mprotect for it.
But it's not enough on some Linux. On my machines sigsegv happened one page
before guard page in this case. I suppose that OS check next page status
before allocate requested page for the stack. And if next page is already
mmapped - OS decides that stack can't grow and sigsegv is happened.
Theoretically stack of the thread can grow infinitely especially on EM64T
platform.

3) I checked mapped areas for the debugged VM and found, that for others
threads, not main thread, whole stack mapped at once. So I tried to map
whole stack for main thread in the beginning of the work, at once. And it
works.



Thanks
Pavel Afremov.

>
> > But  gc.Force and others became fail. The source, as I understand, is in
> > following: after mmap of   the stack, java method Object.wait() can't
> > works.  SuSE 10 hangs up, SuSE 9 makes exit on it
> >
> >
>
> I'm just marveling over the fact you got gdb to work.  Can anyone else
> w/ Ubunutu 32-bit or 64-bit debug drlvm in a reasonable way?
>
>
> >
> > Gdb shows sigsegv in
> >
> > #0  0x0000002a961d489d in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib64/tls/libpthread.so.0
> >
> > #1  0x0000002a957a7501 in apr_thread_cond_wait (cond=Variable "cond" is
> > not available.)
> >
> >     at thread_cond.c:68
> >
> > #2  0x0000002a957a3e85 in condvar_wait_impl (cond=0x2aaa309778,
> > mutex=0x2aaa309728, ms=0, nano=0, interruptable=1)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_condvar.c:69
> >
> >
> > #3  0x0000002a957a4463 in monitor_wait_impl (mon_ptr=0x2aaa3096c8, ms=0,
> > nano=0, interruptable=1)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_fat_monitor.c:208
> >
> >
> > #4  0x0000002a957a652b in thin_monitor_wait_impl
> > (lockword_ptr=0x2a98c24e54, ms=0, nano=0, interruptable=1)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:430
> >
> >
> > #5  0x0000002a957a65b1 in hythread_thin_monitor_wait_interruptable
> > (lockword_ptr=0x2a98c24e54, ms=0, nano=0)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:482
> >
> >
> > #6  0x0000002a96b97f15 in jthread_monitor_timed_wait
> > (monitor=0x7fbfffcbc8, millis=0, nanos=0)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_java_monitors.c:337
> >
> >
> > #7  0x0000002a96a29a08 in Java_java_lang_VMThreadManager_wait
> > (env=0x594c58, clazz=0x7fbfffcbc0, monitor=0x7fbfffcbc8, millis=0,
> nanos=0)
> >
> >     at
> >
> /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/vmcore/src/kernel_classes/native/java_lang_VMThreadManager.cpp:202
> >
> >
> >
> >
> > In HARMONY-2224 <https://issues.apache.org/jira/browse/HARMONY-2224> I
> > excluded failed tests from acceptance test set:
> >
> >     StackTest & exception.FinalizerStackTest on EM64T
> >
> >     gc.LOS on Windows.
> >
>
> I'll go check this out immediately
>
> geir
>
> >
> > BR.
> > Pavel Afremov
> >
> >
> > On 11/17/06, *Geir Magnusson Jr.* <geir@pobox.com
> > <mailto:geir@pobox.com>> wrote:
> >
> >
> >
> >     Rana Dasgupta wrote:
> >      > Not surprising :-) The last big stack relatad checkin in 2018.
> >     Its comment
> >      > notes say that Gregory actually saw the failure of StackTest and
> >     the new
> >      > FinalizeStackTest...
> >
> >     So... lets fix them... :)
> >
> >     geir
> >
> >      >
> >      > On 11/16/06, Geir Magnusson Jr. < geir@pobox.com
> >     <mailto:geir@pobox.com>> wrote:
> >      >>
> >      >> First test that fails is the most cherished and beloved
> >     StackTest, with
> >      >> a segmentation fault :)
> >      >>
> >      >> I'll try to find some more useful info...
> >      >>
> >      >> geir
> >      >>
> >      >>
> >      >> Geir Magnusson Jr. wrote:
> >      >> > We now have DRLVM+Classlib cleanly building out of SVN and
> >     able to run
> >      >> > basic programs on Ubuntu 6 on an em64T box.
> >      >> >
> >      >> > $ uname -a  :
> >      >> >
> >      >> > Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat
> >     Sep 16
> >      >> > 01:50:50 UTC 2006 x86_64 GNU/Linux
> >      >> >
> >      >> > Now starting to look into the test suite.  Tests are passing,
> >     but I've
> >      >> > just started...
> >      >> >
> >      >> > Well done, everyone!
> >      >> >
> >      >> > geir
> >      >> >
> >      >>
> >      >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message