http://bugs.winehq.org/show_bug.cgi?id=16548
Summary: qedit:mediadet.c test is skipped due to renaming a file Product: Wine Version: 1.1.10 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: testcases AssignedTo: wine-bugs@winehq.org ReportedBy: kgbricola@web.de
Created an attachment (id=18023) --> (http://bugs.winehq.org/attachment.cgi?id=18023) hacky mediadet.c test debug patch
GetTempFileNameW() returns sometimes the same name in both calls in mediadet.c. As said in MSDN the name has to be unique. It is unique, but the test deletes the unique file and generates a new one with a new extension. In the next call the GetTempFileNameW() returns another or the same name (the unique file was deleted before).
But the test assumes that renaming the file extension gets a new unique one (which seems to fit on windows XP/2000 - see http://test.winehq.org/data - but not for wine). This works mostly - not all times - in the first run with a clean temp folder. The chance is really small to hit two times the same name.
I haven't checked this on windows but it is affected, too, I think (probably GetTempFileNameW() has an internal static variable which generates every time a new name from the one before, or so ...).
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #1 from Rico kgbricola@web.de 2008-12-17 13:57:32 --- Created an attachment (id=18024) --> (http://bugs.winehq.org/attachment.cgi?id=18024) output from skipped test due to the same filename
This is an example of a run where the file names where in both calls to GetTempFileNameW() the same name. And so the test failed because it renamed the file to the same not unique one!
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #2 from Rico kgbricola@web.de 2008-12-17 14:24:34 --- Created an attachment (id=18025) --> (http://bugs.winehq.org/attachment.cgi?id=18025) hack to get always a unique name
I don't know if this patch is correct. It could override some singes in name if the name is only C:\windows\temp\DES1. In this case the app would do unexpected stuff (Is it possible that GetTempFileNameW() returns such a name?).
So this is only a workaround and needs some improvement. Probably making the prefix longer?
This patch doesn't solve the problem in general, but it makes the chance smaller to get the same name. If the temp folder is clean it will work always. If the temp folder has some files the chance is there to hit a file with the same name.
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #3 from Rico kgbricola@web.de 2008-12-17 14:29:50 --- Probably the renaming should be disabled. The is the only real solution. But I don't know if this affects the tests on any other os (98/XP/...). I couldn't check that here.
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #4 from Austin English austinenglish@gmail.com 2009-06-16 14:24:49 --- Is this still an issue in current (1.1.23 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #5 from Rico kgbricola@web.de 2009-06-17 08:11:42 --- Created an attachment (id=21838) --> (http://bugs.winehq.org/attachment.cgi?id=21838) Trigger the bug in GetTempFileName
Yes, it is still a problem.
Attached is a testcase which shows the bug in the current implementation.
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #6 from Rico kgbricola@web.de 2009-06-17 08:44:35 --- Created an attachment (id=21841) --> (http://bugs.winehq.org/attachment.cgi?id=21841) Patch for GetTempFileName.
This patch makes the previous test happy.
It could be run like this, to check the behaviour: Command: "wine main.exe | uniq | wc" Output on wine without patch: 142 142 4118 Output wine with patch: 1000 1000 27730 Output on windows: 1000 1000 28000
http://bugs.winehq.org/show_bug.cgi?id=16548
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18023|0 |1 is obsolete| | Attachment #18024|0 |1 is obsolete| | Attachment #18025|0 |1 is obsolete| |
--- Comment #7 from Rico kgbricola@web.de 2009-06-17 09:38:02 --- Created an attachment (id=21845) --> (http://bugs.winehq.org/attachment.cgi?id=21845) Do not rename temporary files.
This patch removes the file renaming of the temporary files, which could lead to a skipped test. The next patch shows the problem. It could happen that DeleteFileW fails to delete the file and so on the next run the file already exists.
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #8 from Rico kgbricola@web.de 2009-06-17 09:45:54 --- Created an attachment (id=21848) --> (http://bugs.winehq.org/attachment.cgi?id=21848) Add a check for DeleteFileW
Why does the DeleteFileW-function fail on wine (sometimes with ERROR_SHARING_VIOLATION)? Now on the next run it could happen that the file already exist and the test would be skipped. The previous patch solves the problem until all unique numbers are used (65536).
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #9 from Rico kgbricola@web.de 2009-06-17 11:13:49 --- Created an attachment (id=21850) --> (http://bugs.winehq.org/attachment.cgi?id=21850) Minimal mediadet patch to get sometimes a SHARING_VIOLATION
This hack removes all unneeded stuff from the mediadet test. This show where the problem (timing problem?) comes from. The
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #10 from Rico kgbricola@web.de 2009-06-17 11:59:50 --- Created an attachment (id=21852) --> (http://bugs.winehq.org/attachment.cgi?id=21852) 3 cases with minimal mediadet patch
There are 3 cases with the minimal mediadet patch, which look like timing issues. The test always succeeds with "taskset 0x1 ./wine dlls/qedit/tests/qedit_test.exe.so mediadet".
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #11 from Austin English austinenglish@gmail.com 2010-01-04 16:19:15 --- Rico, would submit those testcases/patches if you haven't already?
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #12 from Rico kgbricola@web.de 2010-01-07 15:34:52 --- Sure I could, but there is an unresolved bug - the 3 cases. I'll have a look at it again.
The other patches only work around some other small problems, where the test would be skipped. But the real problem is, that sometimes the files will not be deleted.
http://bugs.winehq.org/show_bug.cgi?id=16548
--- Comment #13 from Austin English austinenglish@gmail.com 2010-11-25 10:51:13 CST --- I believe this is fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=9f7bc109d20a07367875fc...
http://bugs.winehq.org/show_bug.cgi?id=16548
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #14 from Austin English austinenglish@gmail.com 2010-11-26 12:48:27 CST --- (In reply to comment #13)
I believe this is fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=9f7bc109d20a07367875fc...
Forgot to mark fixed. I ran the tests in a loop 100 times, worked fine.
http://bugs.winehq.org/show_bug.cgi?id=16548
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2010-11-26 13:13:30 CST --- Closing bugs fixed in 1.3.8.
-
wine-bugs＠winehq.org