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 19:29:11 GMT
I think

/**
  *
  * @keyword X_Windows_bug X_Linux_bug
 *
 */

would do it....at least seems to do it for me


On 11/17/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> On 11/17/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >
> > I'm happy to disable tests.
> >
> > I was disappointed in 2224 - I assumed that it was an external "exclude
> > list" :)
> >
> > But I guess that works.  How do we exclude for more than 1 platform?
>
>
>
> It's impossible, as I understand.
>
>
>
> Pavel Afremov
>
> geir
> >
> >
> > Rana Dasgupta wrote:
> > > 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