harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [general] aiming no regression
Date Tue, 19 Dec 2006 11:25:27 GMT
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