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 07:41:32 GMT
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?

Elena

> Rana : works on his 32-bit linux
> >
> > Alexey : pointed out it used to pass, and possible clue, and
> > reports works on SLES9 SMP, both debug and release for jitrino
> >
> > Elena : verified as known bug in em64t, and verified ok for 32-bit
> > SUSE9
> >
> > Geir : stress.Stack passed on a single core Ubuntu 5 ia32
> >
> > So it's been verified on 32 bit linux, both single and multi
> > processor.  The only failures being reported are on RHEL4?
> >
> > So did CC miss this?  Naveen, do you have CC running?  or is this
> > test excluded locally for you?  <Insert standard complaint about
> > local, private CC exclude lists here>
>
> my CC is running, and stress.Stack is passing.
>
> >
> > geir
> >
> >
> >
> >
> >
> >
>
>


-- 
Thanks,
Elena

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