Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
James Hawkins wrote:
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
So were back to fixing the timeouts.
I double checked again and can't see any logging enabled (checked the registry keys your provided).
On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
So were back to fixing the timeouts.
I double checked again and can't see any logging enabled (checked the registry keys your provided).
Of course; there are tons of tests. The timeout needs to be extended, at least for install.c.
James Hawkins wrote:
On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
So were back to fixing the timeouts.
I double checked again and can't see any logging enabled (checked the registry keys your provided).
Of course; there are tons of tests. The timeout needs to be extended, at least for install.c.
I did all kinds of things to try and speed the tests up, to no avail.
The following patch however seems to help:
diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c index 40fabf8..5c7c10c 100644 --- a/dlls/msi/tests/install.c +++ b/dlls/msi/tests/install.c @@ -5415,6 +5415,9 @@ START_TEST(install)
get_program_files_dir(PROG_FILES_DIR, COMMON_FILES_DIR);
+ /* Disable logging */ + MsiEnableLogA(INSTALLLOGMODE_ACTIONSTART, NULL,INSTALLLOGATTRIBUTES_APPEND); + test_MsiInstallProduct(); test_MsiSetComponentState(); test_packagecoltypes();
Even when I now remove that MsiEnableLogA call, it's still within the timeout limit!!
Worthwhile adding to the test?
I did all kinds of things to try and speed the tests up, to no avail.
The following patch however seems to help:
diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c index 40fabf8..5c7c10c 100644 --- a/dlls/msi/tests/install.c +++ b/dlls/msi/tests/install.c @@ -5415,6 +5415,9 @@ START_TEST(install)
get_program_files_dir(PROG_FILES_DIR, COMMON_FILES_DIR);
- /* Disable logging */
- MsiEnableLogA(INSTALLLOGMODE_ACTIONSTART,
NULL,INSTALLLOGATTRIBUTES_APPEND);
- test_MsiInstallProduct(); test_MsiSetComponentState(); test_packagecoltypes();
Even when I now remove that MsiEnableLogA call, it's still within the timeout limit!!
Worthwhile adding to the test?
I tried to do the same on my Vista box (also has timeouts) but I wasn't able to speed that up. It's still 8 minutes or so for just the install test.
James Hawkins wrote:
On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
So were back to fixing the timeouts.
I double checked again and can't see any logging enabled (checked the registry keys your provided).
Of course; there are tons of tests. The timeout needs to be extended, at least for install.c.
Hi,
I just sent a few patches that fix the problem with the timeout on my machines.
Do you think it's still worthwhile to disable logging by using MsiEnableLogA? When I now look in my temp folder I have a few hundred MSI log files. We could either disable logging or create 1 file ourselves and append everything to there (removing it afterwards maybe).
On Sat, Aug 30, 2008 at 3:17 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia adam@tpetaccia.com wrote:
On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote:
Hi,
I was looking into the recent test failures for the msi/package tests on my WinXP box.
The reason for most of them was a stray MSITEST package that couldn't be removed via the 'Add/Remove Programs' (had to remove stuff from the registry).
Any one else seeing this? (Adam Petaccia's XP box has the same issue I guess).
I can provide any details you need about the XP box, the first thing I can think of is that the user running the tests is an administrator.
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
So were back to fixing the timeouts.
I double checked again and can't see any logging enabled (checked the registry keys your provided).
Of course; there are tons of tests. The timeout needs to be extended, at least for install.c.
Hi,
I just sent a few patches that fix the problem with the timeout on my machines.
Do you think it's still worthwhile to disable logging by using MsiEnableLogA? When I now look in my temp folder I have a few hundred MSI log files. We could either disable logging or create 1 file ourselves and append everything to there (removing it afterwards maybe).
Logging to one file takes just as long as any other type of logging. No logging should be happening. No I don't think it's worth using MsiEnableLog to disable loggin. Logging is not enabled by default, and to enable it you have to change some registry entries, which I doubt anyone is doing.
James Hawkins wrote:
On Sat, Aug 30, 2008 at 3:17 PM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
I just sent a few patches that fix the problem with the timeout on my machines.
Do you think it's still worthwhile to disable logging by using MsiEnableLogA? When I now look in my temp folder I have a few hundred MSI log files. We could either disable logging or create 1 file ourselves and append everything to there (removing it afterwards maybe).
Logging to one file takes just as long as any other type of logging. No logging should be happening. No I don't think it's worth using MsiEnableLog to disable loggin. Logging is not enabled by default, and to enable it you have to change some registry entries, which I doubt anyone is doing.
The reason for the 1 file was not to speed up things but to limit the number of logfiles in the temp directory (and maybe the ability to remove this file as we know the one we created ourselves).
On all of my boxes (95/98/NT/W2K/ 2 times XP/W2K3/Vista) I end up with 200 or so logfiles in the temp directory after running the install tests. On none of these boxes did I do anything to tinker with the msi logging settings.
It would be nice if other could tell if they have a huge number of these logfiles in their temp directory after running the tests.
Same thing here with a 2k box running on VirtualBox.
2008/8/31 Paul Vriens paul.vriens.wine@gmail.com
James Hawkins wrote:
On Sat, Aug 30, 2008 at 3:17 PM, Paul Vriens paul.vriens.wine@gmail.com
wrote:
Hi,
I just sent a few patches that fix the problem with the timeout on my machines.
Do you think it's still worthwhile to disable logging by using MsiEnableLogA? When I now look in my temp folder I have a few hundred
MSI
log files. We could either disable logging or create 1 file ourselves
and
append everything to there (removing it afterwards maybe).
Logging to one file takes just as long as any other type of logging. No logging should be happening. No I don't think it's worth using MsiEnableLog to disable loggin. Logging is not enabled by default, and to enable it you have to change some registry entries, which I doubt anyone is doing.
The reason for the 1 file was not to speed up things but to limit the number of logfiles in the temp directory (and maybe the ability to remove this file as we know the one we created ourselves).
On all of my boxes (95/98/NT/W2K/ 2 times XP/W2K3/Vista) I end up with 200 or so logfiles in the temp directory after running the install tests. On none of these boxes did I do anything to tinker with the msi logging settings.
It would be nice if other could tell if they have a huge number of these logfiles in their temp directory after running the tests.
-- Cheers,
Paul.
On Wednesday 27 August 2008 21:15:48 James Hawkins wrote:
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
Would it make sense to have a generic mechanism for cleaning up after a time-out? For example, if the child executable accepted an argument (e.g., /cleanup) that would tell the test to undo any partial state it might have established. For example, it could remove temporary files and some known-test registry entries.
Should a child process timed-out, the parent process could call the child telling it to clear up any mess before continuing with the next test.
I guess timeouts are always possible, it would be nice if the subsequent test-runs were unaffected by this.
HTH,
Paul.
On Thu, Aug 28, 2008 at 7:47 AM, Paul Millar paul@astro.gla.ac.uk wrote:
On Wednesday 27 August 2008 21:15:48 James Hawkins wrote:
That's not why the tests are failing. The install tests are timing out, and if the winetest executable kills the child process that it believes is 'hung', then you're killing the installer process midway through an install and thus leaving the system in a broken state.
Would it make sense to have a generic mechanism for cleaning up after a time-out? For example, if the child executable accepted an argument (e.g., /cleanup) that would tell the test to undo any partial state it might have established. For example, it could remove temporary files and some known-test registry entries.
That's near impossible to do for the install tests.
Should a child process timed-out, the parent process could call the child telling it to clear up any mess before continuing with the next test.
I guess timeouts are always possible, it would be nice if the subsequent test-runs were unaffected by this.
Or we just increase the timeout for legitimately long tests. There's no way to trivially clean up after the install tests. The reason we have timeouts is to kill 'stuck' children, but that's not the case here. The reason some people's machines are in a bad state now is because an install was killed halfway through.
-
Adam Petaccia -
James Hawkins -
Nicolas Le Cam -
Paul Millar -
Paul Vriens