I was hoping you wouldn't say that.
Time to modify the DRLVM build for testing.
<sob>
geir
Pavel Afremov wrote:
On 11/17/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
<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.* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>> > > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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. < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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
>> > > >> >
>> > > >>
>> > > >
>> > >
>> > >
>> >
>>
>>
>