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: [general] aiming no regression
Date Wed, 20 Dec 2006 10:44:41 GMT


Mikhail Loenko wrote:
> I suggest that we don't exclude more tests listed in 2438 -- it seems 
> like any
> swiing test can fail
> 
> Instead we may remove all swing tests from CC when run on J9 and try to 
> fix the
> problem

+1

geir

> 
> Thanks,
> Mikhail
> 
> 
> 2006/12/20, Vladimir Ivanov <ivavladimir@gmail.com>:
>> Actually, I was able to see these failures on swing tests only. But 
>> even for
>> swing these failures reproduced intermittently and only when all swing 
>> tests
>> run in the one VM.
>>
>>
>>
>>  Thanks, Vladimir
>>
>>
>> On 12/19/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>> >
>> > have you seen this stack when other tests run? maybe gui
>> > breaks something causing the failure? Are you able to reproduce the
>> > problem?
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/12/19, Vladimir Ivanov <ivavladimir@gmail.com>:
>> > > On 12/19/06, Ivanov, Alexey A < alexey.a.ivanov@intel.com> wrote:
>> > >
>> > > >
>> > > > There's only one GUI test in your list: 
>> javax.swing.JToggleButtonTest.
>> > > > The others test text model, and this particular tests don't use any
>> > > > swing UI components at all.
>> > > >
>> > > > If I remember your reports correctly, the latter three tests fail
>> > > > because of some serialization failure.
>> > >
>> > >
>> > >
>> > > Yes, testParamString at javax.swing.JToggleButtonTest and
>> > testSerializable
>> > > for other tests. But actually the stack trace is similar (below) so I
>> > think
>> > > it not gui test problem. It is just reproduce this issue.
>> > >
>> > >  Thanks, Vladimir
>> > > Stack trace:
>> > > Test: testParamStringClass: javax.swing.JToggleButtonTest
>> > > java.lang.ArrayIndexOutOfBoundsException
>> > > at java.util.Arrays.mergeSort(Arrays.java:2553)
>> > > at java.util.Arrays.mergeSort (Arrays.java:2516)
>> > > at java.util.Arrays.sort(Arrays.java:2872)
>> > > at java.util.Arrays.sort(Arrays.java:2889)
>> > > at java.beans.BeanInfoWrapper.getPropertyDescriptors(
>> > BeanInfoWrapper.java
>> > > :77)
>> > > at java.beans.BeanInfoWrapper.getPropertyDescriptors(
>> > BeanInfoWrapper.java
>> > > :74)
>> > > at javax.swing.JComponent.paramString(JComponent.java:1334)
>> > > at java.awt.Component.toString(Component.java:166)
>> > > at 
>> javax.swing.JToggleButtonTest.testParamString(JToggleButtonTest.java
>> > :64)
>> > > at 
>> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
>> > > at 
>> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117)
>> > > at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45)
>> > > at 
>> java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92)
>> > > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java :81)
>> > > at java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:133)
>> > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:144)
>> > > at 
>> java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
>> > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>> > >
>> > > Test: testSerializableClass:
>> > > javax.swing.text.AbstractDocument_SerializationTest
>> > > java.lang.ArrayIndexOutOfBoundsException
>> > > at java.util.Arrays.mergeSort(Arrays.java:2553)
>> > > at java.util.Arrays.mergeSort(Arrays.java:2516)
>> > > at java.util.Arrays.mergeSort(Arrays.java:2517)
>> > > at java.util.Arrays.sort(Arrays.java:2872)
>> > > at java.util.Arrays.sort(Arrays.java:2889)
>> > > at java.io.ObjectStreamClass.computeSerialVersionUID(
>> > ObjectStreamClass.java
>> > > :54)
>> > > at java.io.ObjectStreamClass.addToCache(ObjectStreamClass.java:211)
>> > > at java.io.ObjectStreamClass.lookupStreamClass(ObjectStreamClass.java
>> > :937)
>> > > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:90)
>> > > at java.io.ObjectStreamClass.addToCache(ObjectStreamClass.java :23)
>> > > at java.io.ObjectStreamClass.lookupStreamClass(ObjectStreamClass.java
>> > :937)
>> > > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:90)
>> > > at java.io.ObjectOutputStream.writeClassDescForClass(
>> > ObjectOutputStream.java
>> > > :110)
>> > > at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java
>> > :1644)
>> > > at java.io.ObjectOutputStream.writeObjectInternal(
>> > ObjectOutputStream.java
>> > > :1956)
>> > > at java.io.ObjectOutputStream.writeObject 
>> (ObjectOutputStream.java:1785)
>> > > at 
>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1749)
>> > > at javax.swing.BasicSwingTestCase.serializeObject(
>> > BasicSwingTestCase.java
>> > > :496)
>> > > at javax.swing.SerializableTestCase.setUp 
>> (SerializableTestCase.java:50)
>> > > at javax.swing.text.AbstractDocument_SerializationTest.setUp
>> > > (AbstractDocument_SerializationTest.java:43)
>> > >
>> > >
>> > > > Regards,
>> > > > Alexey.
>> > > >
>> > > > >
>> > > > >
>> > > > >On 12/18/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> Mikhail Loenko wrote:
>> > > > >> > 2006/12/18, Geir Magnusson Jr. <geir@pobox.com >:
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> Mikhail Loenko wrote:
>> > > > >> >> > 2006/12/1, Geir Magnusson Jr. <geir@pobox.com>:
>> > > > >> >> >>
>> > > > >> >> >>
>> > > > >> >> >> Mikhail Loenko wrote:
>> > > > >> >> >> > 4) We have cruise controls running
classlibrary tests on
>> > > > DRLVM.
>> > > > >We
>> > > > >> >> >> > need to decide what will we do when
DRLVM+Classlib 
>> cruise
>> > > > control
>> > > > >> >> >> > reports failure.
>> > > > >> >> >>
>> > > > >> >> >> Stop and fix the problem.  Is there really
a question
>> > here?  I
>> > > > >agree
>> > > > >> >> >
>> > > > >> >> > Yes, there is a question here. "Stop and fix"
includes
>> > > > "discuss".
>> > > > >But
>> > > > >>
>> > > > >> >> > as we now know discussion may take several
days. And while
>> > some
>> > > > >> people
>> > > > >> >> > discuss what the problem is other people can't
proceed with
>> > > > >> >> > development and patch
>> > > > >> >> > intagration.
>> > > > >> >> >
>> > > > >> >> > To have better pace and better CC up-time we
need something
>> > else
>> > > > but
>> > > > >> >> not
>> > > > >> >> > just "stop and fix". I suggest "revert and
continue"
>> > > > >> >>
>> > > > >> >> What's the difference, other than debating the semantics
of
>> > "fix"
>> > > > and
>> > > > >> >> "revert"?
>> > > > >> >>
>> > > > >> >> We all agree - but I still don't think you're clearly
stating
>> > the
>> > > > >> >> problem.  I think that the core problem is that
we don't
>> > > > immediately
>> > > > >> >> react to CC failure.
>> > > > >> >>
>> > > > >> >> Immediately reacting to CC failure should be the
first 
>> order of
>> > > > the
>> > > > >day
>> > > > >> >> here.  Reacting to me is making the decision, quickly,
about
>> > > > either
>> > > > >> >> rolling back the change ("reverting") or doing something

>> else.
>> > > > The
>> > > > >key
>> > > > >>
>> > > > >> >> is being responsive.
>> > > > >> >>
>> > > > >> >> It seems that what happens is that we wait, and
then sets of
>> > > > changes
>> > > > >> >> pile up, and I think that doing mass rollbacks at
that point
>> > will
>> > > > >solve
>> > > > >> >> it, but make a mess.
>> > > > >> >>
>> > > > >> >> The example of what I envision is when I broke the
build in
>> > DRLVM,
>> > > > >> >> Gregory told me immediately, and I fixed immediately
- w/o a
>> > > > rollback.
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> All I'm saying is :
>> > > > >> >>
>> > > > >> >> 1) We need to be far better with reaction time
>> > > > >> >
>> > > > >> > I would say we need to be far better with fixing/reverting

>> time.
>> > > > >> > If we reacted immediately and than discussed for two
weeks 
>> -- we
>> > > > would
>> > > > >> not
>> > > > >> > be better than where we are now
>> > > > >>
>> > > > >> Yes, fixing/reverting is included. It's what I meant.
>> > > > >>
>> > > > >> >
>> > > > >> >>
>> > > > >> >> 2) We have intelligent people - we can be agile
in this by
>> > making
>> > > > >> >> decisions (quickly!) on a case by case basis what
to do.
>> > > > >> >>
>> > > > >> >> I'll also suggest that we ask each committer to
check the CC
>> > event
>> > > > >> >> stream before committing, so you don't commit into
a bad 
>> state
>> > of
>> > > > >> things.
>> > > > >> >>
>> > > > >> >> One of my problems is that I don't trust the CC
stream, and
>> > don't
>> > > > >> >> clearly see it because it's mixed in the other drek
of the
>> > > > commits@
>> > > > >> list.
>> > > > >> >
>> > > > >> > The problem is intermittent failures. I suggest that
we 
>> exclude
>> > > > >graphics
>> > > > >> > tests
>> > > > >> > from CCs and probably have CC-specific exclude lists
for
>> > networking
>> > > > >> tests
>> > > > >> > (or fix all the known intermittent failures right now
:)
>> > > > >>
>> > > > >> good idea - works for me.
>> > > > >>
>> > > > >> We need to drive into stability - we've made amazing progress
in
>> > the
>> > > > >> last two months, and now we're down to the really, really
hard
>> > stuff.
>> > > > I
>> > > > >> think that excluding them to get rock-solid CC reporting
is 
>> step 0,
>> > > > >> and then step 1 is try and grind out the intermittent failures.
>> > > > >>
>> > > > >> geir
>> > > > >>
>> > > > >>
>> > > >
>> > > > --
>> > > > Alexey A. Ivanov
>> > > > Intel Enterprise Solutions Software Division
>> > > >
>> > >
>> > >
>> >
>>
>>

Mime
View raw message