harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Neelakantam <neela...@uiuc.edu>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Thu, 11 Jan 2007 22:53:10 GMT

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.  :-)

> 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
>
>
>
>
>
>


Mime
View raw message