Mailingliste - Einträge 2005

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

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,

"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           
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876