On 1/25/07, Pavel Afremov <[EMAIL PROTECTED]> wrote:
SOE implementeation for x86_64 platform was not contributed due a bug in threading system. SOE for x86_32 should works on any platform. Weldon When did you notice that on your x86_32 machine? Did it works before or you didn't run tests on your RHEL4 machine before? I think that StackTest should be excluded. We should find changes which is source of the crash.
Pavel, StackTest, stress.Stack and exception.FinalizeStackTest are excluded for Linux x86_64 and *http://issues.apache.org/jira/browse/HARMONY-2972* has been filed to track this issue. Could you please add a comment to this issue? Besides, the overall picture of excluded smoke tests could be seen in the http://wiki.apache.org/harmony/DRLVMInternalTests page Elena
Thanks. Pavel Afremov. On 1/15/07, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > On 1/14/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > Geir Magnusson Jr. wrote: > > > > > > On Jan 12, 2007, at 7:53 AM, Gregory Shimansky wrote: > > > > > >> Elena Semukhina wrote: > > >>> I tried StackTest in jitrino debug mode on both SUSE9 linux 2 CPU > > >>> ia32 and > > >>> em64t machines. It passed. It is now excluded for linux x86_64 > > (probably > > >>> Geir has excluded it because it always passed for me). > > >>> I ran it on that platform and saw rather strange behavior. The test > is > > >>> essentially the same as stress.Stack: both tests invoke a method > > >>> recursively > > >>> waiting for StackOverflowError. The difference is that the method is > > >>> void in > > >>> StackTest and boolean in stress.Stack. Another difference is that > > >>> StackTest > > >>> should never fail: it detects both throwing StackOverflowError and > not > > >>> throwing it as normal situation. Doing that it passes even with > > >>> 200000000 > > >>> iterations with no StackOverflowError (!) (JIT) while on RI it gets > > >>> StackOverflowError after 650000 iterations. On drlvm linux ia32 it > > gets > > >>> exception after 8600 iterations. It also gets the exception in > > >>> interpreter > > >>> mode on em64t (about 2400 iterations). > > >>> Can this be correct behavior? > > >> > > >> If you use SuSE9 on x86_64, then most likely it is because of > > >> weirdness of SuSE9 installation. It has no hard or soft stack limit > by > > >> default (see ulimit -s). You can try to limit stack size like ulimit > > >> -s 8192 and then this test should not give too many iterations. If > you > > >> upgrade to SuSE10, you will see that it has default stack limit 8192. > > >> > > >> The current implementation of SOE in drlvm is that it takes stack > size > > >> from the system. If system has no limit, then stack has no limit as > > >> well. It has been discussed in other threads about SOE that this is > > >> not very good, but hasn't been fixed AFAIK. > > >> > > > > > > I think that if we can find a way to have an "cononical environment" > for > > > linux that get set before running the tests, that would be useful. > > > > I agree. I think the easiest way would be to implement -Xss option for > > drlvm and use it for those tests which actually depend on stack size > > like StackTest and stress.Stack. > > > This task is already declared at > http://wiki.apache.org/harmony/CoreVmDevelopmentItems page. > I think there should be also a default stack size value for the systems > with > unlimited stack size. The test shows that RI definitely limits stack size > on such systems. > > BTW, should we also change the test so that it fails after creating a huge > number of stack frames? > > Elena > > > > > -- > > Gregory > > > > > > > -- > Thanks, > Elena > >
-- Thanks, Elena
