harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 12 Jan 2007 12:53:23 GMT
Elena Semukhina wrote:
> On 1/12/07, Naveen Neelakantam <neelakan@uiuc.edu> wrote:
>>
>>
>> On Jan 11, 2007, at 12:28 PM, Geir Magnusson Jr. wrote:
>>
>> >
>> > On Jan 11, 2007, at 9:19 AM, Weldon Washburn wrote:
>> >
>> >> On 1/11/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> >>>
>> >>> Weldon Washburn wrote:
>> >>> > This actually brings up something that would really be nice to
>> >>> have, a
>> >>> > rollback list.  I am thinking a short list of OS/HW combos that
a
>> >>> > regression means a compulsory SVN rollback.  The expectation is
>> >>> that
>> >>> every
>> >>> > committer would have access to a full set of machines on the
>> >>> rollback
>> >>> list.
>> >>> > For starts, I think the list should be:
>> >>> >
>> >>> > 1)
>> >>> > single ia32 cpu laptop  w/ WindowsXP
>> >>> > 2)
>> >>> > 4 CPU SMP w/ Linux ia32
>> >>> > 3)
>> >>> > 4 CPU SMP w/ Linux 64-bit (em64t)
>> >>> >
>> >>> >
>> >>> > Thoughts?
>> >>>
>> >>> Cool -- do I send my shipping address to you? :-)
>> >>>
>> >>> How can you make such an expectation?
>> >>
>> >>
>> >> I don't know what the answer is.  We are really caught between a
>> >> rock and a
>> >> hard spot.  The current path leads to each committer holding a
>> >> private list
>> >> of exclude tests.  Then when someone says your last mod breaks on my
>> >> machine, we do a rollback to a stable revision.  And then sort of
>> >> kind of
>> >> let someone else with different hardware try to fix the patch,
>> >> commit then
>> >> wait to see if anyone complains.
>> >
>> > That's what the community-owned build-cloud is for.   Do your due
>> > diligence on your machine(s), and let CC tell you when there's a
>> > problem.
>> >
>> > My original concern is that you found a problem that CC apparently
>> > missed.  I think figuring this out is higher priority than GCv5 :)
>> > (I'll help out myself if I can get the failure to occur - testing
>> > as I write this... nope, didn't fail)
>> >
>> > Right now, tallying the thread :
>> >
>> > Weldon : fails on RHEL4 2 CPU
>> >
>> > Naveen : fails on RHEL4, jitrino debug mode (is that only in debug?)
>>
>> Whoops, sorry for the confusion.
>>
>> I was talking about StackTest not stress.Stack.  I'm not sure if
>> there is a relationship, but if I were trying to debug this problem I
>> would try building jitrino in debug mode and note that StackTest
>> explodes.
>>
>> But the world being the way that it is, it is probably more likely
>> that the StackTest failure is a completely unrelated bug.  :-)
> 
> 
> 
> 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.

-- 
Gregory


Mime
View raw message