harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 12 Jan 2007 13:06:21 GMT
On 1/12/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> 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, you are right: the stack was unlimited on my system. When I set it
to 8192, the StackTest crashed immediately with seg fault.


--
> Gregory
>
>


-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message