Mailing list - Entries of 2006


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qftestJUI] A possible race condition


  • Subject: Re: [qftestJUI] A possible race condition
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 21 Mar 2006 16:59:47 +0100

Hi Leonid,

thanks for the update.

I consider qftest's behavior broken in this case and we will fix it
for the next release, but if you don't need a patch that's fine with
me :-).

Best regards,
    Greg

"Kosmylev, Leonid" <Leonid.Kosmylev@?.com> writes:

> Well, 
> 
> I confirmed that qftestJUI indeed "hides" an exception thrown by runnable: I
> created a simple runnable that always throws a RuntimeException, and passed
> it into SwingUtilities.invokeLater().
> While the application itself reacts on the first occurance of the
> RuntimeException by displaying an error message box, if the application is
> executed under qftestJUI no error message box is displayed, the runnable is
> invoked twice, and stack traces are the same as in our original problem.
> 
> But now our original problem disappeared as suddenly as it has appeared one
> week ago (or maybe it is my debugging code at the end of that "thin wrapper"
> affects execution so dramatically that the problem disappeared). I will
> continue some experimets, but if the problem will not be reproduced I will
> have to let it go.
> 
> As for version of qftestJUI: I was no involved in that originally, I am not
> involved in this at the moment either - I am just investigating the problem
> we have got. My quess would be: "if it ain't broken do not fix it".
> 
> Regards,
> 
> Leonid
> 
> 
> 
> -----Original Message-----
> From: Gregor Schmid [mailto:Gregor.Schmid@?.de] 
> Sent: Tuesday, March 21, 2006 14:39
> To: Kosmylev, Leonid
> Subject: Re: [qftestJUI] A possible race condition
> 
> 
> Hi Leonid,
> 
> have you found anything yet?
> 
> Independent of that, I'd like to create a fix for the problem, but I cannot
> create a patch against qftestJUI version 1.06.0 which is almost two years
> out of date. Is there any reason why you're not using our latest and
> greatest version 1.08.5?
> 
> Best regards,
>     Greg
> 
> "Kosmylev, Leonid" <Leonid.Kosmylev@?.com> writes:
> 
> > Hi.
> > 
> > Actually our application is just a set of plugins to some other 
> > application, and that one installs its EventQueue.
> > 
> > Now, I tried to do try/catch/finally around the runnable (I suspected 
> > some kind of retry, but actually from the application itself, not from 
> > qftestJUI), and our runnable DID not throw any exception. That is why 
> > I suspected some race conditions.
> > 
> > But your answer got me thinking... Actually what happens is that there 
> > is a thin wrapper around our quite complex runnable. I know for sure 
> > our runnable does not throw any exceptions, but that thin wrapper is 
> > another story. I did not checked it yet. It is the next thing I will try
> to do next week.
> > 
> > Thanks for the answer.
> > 
> > Leonid
> > 
> > 
> > 
> > -----Original Message-----
> > From: Gregor Schmid [mailto:Gregor.Schmid@?.de]
> > Sent: Friday, March 17, 2006 15:51
> > To: qftestJUI-list@?.de
> > Cc: Kosmylev, Leonid
> > Subject: Re: [qftestJUI] A possible race condition
> > 
> > 
> > Hello Leonid,
> > 
> > interesting observation. Looks like your Runnable is throwing an 
> > uncaught exception. ALso, your app appears to install its own EventQueue.
> > 
> > What happens is that qftest tries to dispatch the event through your 
> > EventQueue and if that fails it dispatches the event itself. Looks 
> > like qftest should put more effort in trying to detect where the 
> > exception acually comes from. If the event was properly dispatched 
> > through your queue but the EventListener (or the Runnable in this
> > case) throws an exception, that exception should be passed on and the 
> > Event not redispatched.
> > 
> > Can you confirm this theory by adding a try/catch to the respective 
> > runnable?
> > 
> > Best regards,
> >     Greg
> > 
> > "Kosmylev, Leonid" <Leonid.Kosmylev@?.com> writes:
> > 
> > > Hi,
> > > 
> > > We are using qftestJUI version 1.06.0 (build 919) to test our 
> > > product, mostly on linux ("uname -r" reports 2.6.11-1.1369_FC4smp).
> > > 
> > > Recently we started to run into a very strange problem which was 
> > > tracked to qftestJUI itself.
> > > 
> > > We have piece of code that looks like this:
> > > 
> > > Runnable  r = ...;
> > > SwingUtilities.invokeLater(r);
> > > 
> > > Where the runnable is doing quite a lot, including but not limiting 
> > > to swing calls. Sometimes (approx. 15%-20% of our test runs) the 
> > > code in the runnable is invoked twice.
> > > 
> > > We put some debugging output (Thread.dumpStack()) in the runnable's
> > > run() method.
> > > 
> > > Results:
> > > Test runs where the runnable is invoked once have the following output:
> > > 
> > >         at <Our runnable's run() method> 
> > >         at
> > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> > >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> > >         at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> > >         at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
> > > ss
> > > orImpl
> > > .java:25)
> > >         at java.lang.reflect.Method.invoke(Method.java:324)
> > >         at de.qfs.lib.util.Reflector.call(Reflector.java:112)
> > >         at
> > >
> > de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> > a:223)
> > >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> > >         at
> > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > > hr
> > > ead.ja
> > > va:201)
> > >         at
> > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > > ea
> > > d.java
> > > :151)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> > >         at
> > > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > > 
> > > 
> > > Test runs where the runnable is invoked twice have the following output:
> > > 1. First invocation (note that is it the same as the one above):
> > > 
> > >         at <Our runnable's run() method> 
> > >         at
> > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> > >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> > >         at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
> > >         at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
> > > ss
> > > orImpl
> > > .java:25)
> > >         at java.lang.reflect.Method.invoke(Method.java:324)
> > >         at de.qfs.lib.util.Reflector.call(Reflector.java:112)
> > >         at
> > >
> > de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> > a:223)
> > >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> > >         at
> > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > > hr
> > > ead.ja
> > > va:201)
> > >         at
> > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > > ea
> > > d.java
> > > :151)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> > >         at
> > > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > > 
> > > 2. Second invocation:
> > > 
> > >         at <Our runnable's run() method> 
> > >         at
> > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> > >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> > >         at de.qfs.lib.gui.EventQueue.doDispatch(EventQueue.java:656)
> > >         at
> > >
> > de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> > a:240)
> > >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> > >         at
> > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > > hr
> > > ead.ja
> > > va:201)
> > >         at
> > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > > ea
> > > d.java
> > > :151)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> > >         at
> > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> > >         at
> > > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > > 
> > > Note that in the "normal" case the event is dispatched at line 
> > > TestEventQueue.java:223, while the abnormal second case is coming 
> > > from TestEventQueue.java:240
> > > 
> > > What is also strange that we use SwingUtilities.invokeLater in a lot 
> > > of places but it looks like at the moment we have the problem with 
> > > it only in one particular place.
> > > 
> > > Of course it is easy to work around this particular problem just by 
> > > adding flag "alreadyExecuted" to the runnable, but what we do not 
> > > want to do is to add such a flag to _each_ place where we use
> > SwingUtilities.invokeLater().
> > > 
> > > Everything points to a potential race condition in class
> > > TestEventQueue: for some reasons sometimes it "forgets" that an 
> > > event was already processed (?)
> > > 
> > > Has anybody else seen such a problem? 
> > > 
> > > Regards,
> > > 
> > > Leonid Kosmylev

-- 
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876


Videos Downloads Documentation Buy Free Trial