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
> >> > > >> >
> >> > > >>
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >
>
|