harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][x86_64] status update
Date Fri, 17 Nov 2006 18:35:15 GMT
Hi,
   Sadly, I still run or debug any of this yet. But my suggestion and
request would be that we commit Pavel's patch 2224 which for now disables
the overfow tests on EM64T. That would give us some time to understand and
debug the problem. We are good on 32 bit.
   The bottom line is that the main thread stack growth and mapping
behaviour and guard paging seems to vary across Linux implementations,
specially between older and more current implementations. Some behaviour
could also be specific to SUSE. We will figure out what is the best and
broadest solution.

Thanks,
Rana

On 11/17/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
>
>
>
>
> 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