Should winetest retrieve msi log file on msi test failures?

James Hawkins truiken at gmail.com
Wed Jan 28 17:18:36 CST 2009


On Wed, Jan 28, 2009 at 3:12 PM, Dan Kegel <dank at kegel.com> wrote:
> On Wed, Jan 28, 2009 at 12:14 PM, James Hawkins <truiken at gmail.com> wrote:
>>> http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/xp_fg-winxp-ie7/msi:msi.html
>>> says
>>> dlls/msi/tests/msi.c
>>> msi.c:254: Test failed: wrong error 1618
>>>
>>> 1618 is ERROR_INSTALL_ALREADY_RUNNING.
>>
>> ...  There error is ERROR_INSTALL_ALREADY_RUNNING
>> because the test before msi.c timed out (but is still running).
>
> So I guess the existing report has enough info.
>
> Does this happen enough that we should clean up after timed out msi
> tests better somehow?
>

Just the opposite.  We've made a lot of efforts before to cut down the
test time for msi tests (always a struggle).  That's the direction to
continue moving.  The problem is that winetest only kills a timeout
process when the user running the winetest clicks the 'Ok' button on
the timeout dialog.  IMO winetest should just kill the process no
matter what, or only depend on the message box when the tests are
interactive.  That's not a real solution to the problem though, as
there is still a race between the msiexec process finishing the
current install and the next msi test starting.

One more piece of information I forgot to say in the first email.
Adding logging is definitely out of the question, because that
increases the running time of the msi tests tremendously.  The real
problem is users running winetest on boxes that are severely shut down
as far as user restrictions go.  We need to find a way to test for
this condition before trying to run the msi tests.  When the boxes are
that closed off, msi practically isn't allowed to do anything and all
of the tests fail.

-- 
James Hawkins



More information about the wine-devel mailing list