James:
From: James Hawkins truiken@gmail.com Sent: Sep 1, 2008 10:49 AM To: James Mckenzie jjmckenzie51@earthlink.net Cc: Paul Vriens paul.vriens.wine@gmail.com, "wine-devel@winehq.org" wine-devel@winehq.org Subject: Re: Recent msi/package tests failures
On Mon, Sep 1, 2008 at 10:18 AM, James Mckenzie jjmckenzie51@earthlink.net wrote:
Paul/James: Paul Vriens wrote:
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.
+1 to one log file. I hate having to look through piles of log files to find errors. Yes, I know that I could grep them, but that is an added step that should not be needed.
Why would you be grep'ing windows msi log files?
grep is the tool of choice when working with Linux/UNIX text files and searching through thousands of them. If this process is run on Wine in the state that I understand it is, and I may be incorrect, thousands of logging files may be created. Also it is less resource intensive to search one text file under Windows, unless the file is very, very large (> 1 MB). Searching a directory of thousands of files can take a long time (I have experience with this.) One file per run is all that should be created, IMHO.
James McKenzie
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
James:
+1 to one log file. I hate having to look through piles of log files to find errors. Yes, I know that I could grep them, but that is an added step that should not be needed.
Why would you be grep'ing windows msi log files?
grep is the tool of choice when working with Linux/UNIX text files and searching through thousands of them.
Don't patronize me. If you can't be mature on this list, then don't post.
If this process is run on Wine in the state that I understand it is, and I may be incorrect, thousands of logging files may be created.
Incorrect. Logging is not implemented in Wine's msi, and probably never will be as we have our own logging mechanism.
Also it is less resource intensive to search one text file under Windows, unless the file is very, very large (> 1 MB). Searching a directory of thousands of files can take a long time (I have experience with this.)
That doesn't answer the question of why you, a winetest user in this sense, would be searching through windows installer logs after running the tests.
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
On Tue, Sep 2, 2008 at 12:45 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
It's not worth messing with. The slowdown is because of the restore points, and that has been solved, so hopefully the patches will be accepted and we won't have any timeouts. On my Server 2008 system, logs are created that usually contain just one line about whatever error was being tested. I haven't tested whether MsiEnableLog affects that, but my guess is it doesn't. Either way, those are just one line log files in a temp directory.
James Hawkins wrote:
On Tue, Sep 2, 2008 at 12:45 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
It's not worth messing with. The slowdown is because of the restore points, and that has been solved, so hopefully the patches will be accepted and we won't have any timeouts. On my Server 2008 system, logs are created that usually contain just one line about whatever error was being tested. I haven't tested whether MsiEnableLog affects that, but my guess is it doesn't. Either way, those are just one line log files in a temp directory.
So we can say that logfiles are created, although they only contain 1 line per logfile (this is the same on my boxes).
I did test with MsiEnableLog and it does effect the creation of these files.
I'm in favor of using MsiEnableLog to create just one logfile in the temp directory. It doesn't need to be removed as it could be used for all kinds of other purposes. I do like it however that there are hardly leftovers after running winetest.
On Tue, Sep 2, 2008 at 12:55 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Tue, Sep 2, 2008 at 12:45 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
It's not worth messing with. The slowdown is because of the restore points, and that has been solved, so hopefully the patches will be accepted and we won't have any timeouts. On my Server 2008 system, logs are created that usually contain just one line about whatever error was being tested. I haven't tested whether MsiEnableLog affects that, but my guess is it doesn't. Either way, those are just one line log files in a temp directory.
So we can say that logfiles are created, although they only contain 1 line per logfile (this is the same on my boxes).
I did test with MsiEnableLog and it does effect the creation of these files.
I'm in favor of using MsiEnableLog to create just one logfile in the temp directory. It doesn't need to be removed as it could be used for all kinds of other purposes. I do like it however that there are hardly leftovers after running winetest.
If MsiEnableLog has any affect, and people are bothered by small log files in a temp directory, then all you need is one call to MsiEnableLog in the beginning of the tests to disable logging.
/* disable logging */ MsiEnableLog(0, NULL, 0);
On Tue, Sep 2, 2008 at 12:45 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
-- Cheers,
Paul.
FWIW, my work XP box times out on quite a few tests, but has system restore disabled.
-Austin
Austin English wrote:
On Tue, Sep 2, 2008 at 12:45 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Mon, Sep 1, 2008 at 8:08 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
One file per run is all that should be created, IMHO.
No, zero log files should be created. This discussion is about reducing the time it takes to run the tests, and any logging hinders that effort.
OK, back to the initial discussion then.
I did find that 'System Restore' was the cause of the slowdown on a lot of (at least) XP and Vista systems. Patches are being sent for that.
Disabling logging as I suggested at first only helps to get rid of a few seconds from the total run time of these tests. The question remains however why some people have loads of log files in their temp directory and some don't.
Do you think that for testing purposes we could add a check in the install tests that shows us the number of MSI logfiles in the temp directory before and afterwards? Or is it enough that several people already responded to my question about those logfiles?
-- Cheers,
Paul.
FWIW, my work XP box times out on quite a few tests, but has system restore disabled.
-Austin
Yes, the same happens to other boxes when looking at test.winehq.org. 'System Restore' is definitely one of the causes but we are not there yet.
The other (non msi) timeouts are most likely not influenced by the system restore facility but have to be fixed as well (most noticeably dplayx).
Austin English wrote:
FWIW, my work XP box times out on quite a few tests, but has system restore disabled.
-Austin
Hi Austin,
Could you check something for me on your XP box?
According to http://test.winehq.org/data/5e1ac66b258415a33d96bb983c7e2ec3c7eea968/xp_aeng..., there are some leftovers from old tests in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\debugger registry value. Is that correct?
Could you run 'drwtsn32 -i' from a command prompt before you run a next winetest? That will at least put that to a much saner value (the Windows out-of-the-box default).
On Thu, Sep 4, 2008 at 2:07 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Austin English wrote:
FWIW, my work XP box times out on quite a few tests, but has system restore disabled.
-Austin
Hi Austin,
Could you check something for me on your XP box?
According to http://test.winehq.org/data/5e1ac66b258415a33d96bb983c7e2ec3c7eea968/xp_aeng..., there are some leftovers from old tests in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\debugger registry value. Is that correct?
C:\DOCUME~1\Admail\LOCALS~1\Temp\wct16\kernel32_test.exe debugger dbg,attach,event,code2 C:\DOCUME~1\Admail\LOCALS~1\Temp\wt38.tmp %ld %ld
Could you run 'drwtsn32 -i' from a command prompt before you run a next winetest? That will at least put that to a much saner value (the Windows out-of-the-box default).
Still times out on quite a few. Here are the results:
http://test.winehq.org/data/6e90756307bfd5aa6ce2207f9419dabd26f46ec6/#group_... http://test.winehq.org/data/6e90756307bfd5aa6ce2207f9419dabd26f46ec6/xp_aeng...
Any other ideas/tests needed, let me know.
-Austin
-
Austin English -
James Hawkins -
James Mckenzie -
Paul Vriens