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 <[EMAIL PROTECTED]> wrote:
On 11/17/06, Geir Magnusson Jr. <[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]> 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.* <[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]>> 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 > >> > > >> > > >> > > >> > >> > > > > >> > > > >> > > > >> > > >> > >> > > >
