Mailing list - Entries of 2005

Re: [qftestJUI] deadlock problem

Subject: Re: [qftestJUI] deadlock problem

From: Gregor Schmid <Gregor.Schmid@?.de>

Date: Thu, 14 Apr 2005 12:22:06 -0000

Hello Alvin,
thanks for the thread dump. In this case the deadlock is actually
caused by a bug in qftest which originates in an attempt to prevent
just such deadlocks.
There is a weakness in the AWT code involving class locks which,
combined with buggy code that creates AWT windows from a non-AWT
thread (often used for splash screens), could cause qftestJUI to
trigger such a deadlock. Though qftestJUI was correct in that case, it
is very hard to explain to users why their app freezes under qftest
when it doesn't freeze outside.
The irony here is that your thread dump shows that this workaround
fails if not just one, but two monitors are involved, thus leading to
a deadlock in a correctly implemented SUT.
You should be able to prevent it from happening by setting the option
"Run-log->Content->Number of events to log for error diagnosis" to 0
as these error diagnosis logs invoke Component.toString() a lot which
ultimately triggers the problem.
If that doesn't work, drop me a note and I'll create a patch for you.
I think the long-term solution will be to disable the diagnostic logs
by default, remove our imperfect workaround and take our chances with
buggy apps...
Best regards,
Greg
"Alvin Fajardo" <Alvin.Fajardo@?.com> writes:
> I am getting a deadlock when an error dialog pops up in my SUT. I
> have attached the thread dump. Is this a bug with qftestJUI or a
> problem with my SUT?
>
>
> Thanks,
>
> Alvin
--
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