harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 12 Jan 2007 23:39:06 GMT

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.


View raw message