http://bugs.winehq.org/show_bug.cgi?id=20204
Summary: MacOS: enhanced metafile retrieval fails and crashes clipboard test Product: Wine Version: 1.1.25 Platform: PC OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: huw@codeweavers.com
Huw Davies' post 1.1.24 commit 7490f922e0adaacbf5396cf8afdc90e33bc1a808 "test for enhanced metafile retrieval" fails on MacOS. After a variable amount of output about getdata and next, I see clipboard.c:1356: Test failed: got 80004005 clipboard.c:1358: Test failed: got 0
Alas, the testsuite randomly crashes afterwards, because ReleaseStgMedium() is not called only if(SUCCEEDED(hr)). In fact, n-1 occurrences of ReleaseStgMedium in that file are not guarded. Therefore, the actual error was not spotted until now.
Curiously, gcc -O0 tests/clipboard.c tends to crash less or show no crash dialog at all. That may explain why using winetest.exe did not spot this defect earlier. Sometimes test runs report no failure, it's just the missing summary line that reveals the problem.
With the guard in place, the testsuite always runs to completion (with the above 2 errors out of 381 tests).
http://bugs.winehq.org/show_bug.cgi?id=20204
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2009-09-29 04:33:11 --- The missing guard of ReleaseStgMedium also explains the crash on Fedora http://test.winehq.org/data/f3b9fb554dd116c881422098738a1f0223087cd1/wine_as... clipboard.c:1356: Test failed: got 80040064 clipboard.c:1358: Test failed: got 0 =>0 0x684074aa ReleaseStgMedium
Of course, that does not explain why the clipboard metafile retrieval fails with such curious errors on Fedora Core and MacOS but succeeds on Ubuntu Intrepid.
http://bugs.winehq.org/show_bug.cgi?id=20204
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|MacOS: enhanced metafile |enhanced metafile retrieval |retrieval fails and crashes |fails and crashes clipboard |clipboard test |test
http://bugs.winehq.org/show_bug.cgi?id=20204
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
http://bugs.winehq.org/show_bug.cgi?id=20204
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2009-09-30 11:30:41 --- commit 08df19b40510f37d89bb7740abcacfa6ad246f91 about ReleaseStgMedium fixed the causes of the crashes. Now test.winehq will start to show reproducable results for ole32:clipboard.
Hmm, maybe the variability of results about marshal.ok http://test.winehq.org/data/tests/ole32:marshal.html can be explained by a similar bad usage of destructors?
http://bugs.winehq.org/show_bug.cgi?id=20204
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2009-11-04 09:00:33 --- http://test.winehq.org/data/tests/ole32:clipboard.html shows that perhaps the patch helped produce a period of stability without crashes lasting for 15 days. Since then, only 64bit machines crashed, sometimes.
That is possibly independent on the present issue. Should this issue be closed or wait until test results stabilize?
Regarding ReleasStgMedium(), I must say that although I contributed the obvious patch, it would help if somebody who knows OLE could look after the cause of the randomness. I fail to understand the Release protocol. I find it illogical that the following pattern is used in tests/clipboard.c.
Either: InitFormatEtc() med.x=GlobalAlloc / CreateStream / StgCreateDocFile hr=GetDataHere(med) ReleaseStgMedium(med) /* unconditionaly because we allocated resources */ Or: InitFormatEtc() hr=GetDataHere(med) if (SUCCEEDED(hr)) ReleaseStgMedium(med) /* random crashes if not guarded */
I mean, if Release is only mandatory in the first case (to free the Alloc), why do we need it at all in the second case?
Note that on my (Linux) machine 10 consecutive invocations of clipboard.ok produce 3 different error patterns (all in test_getdatahere), sometimes no error. When it fails, getdatahere returns 80040064 (like other people's results on test.winehq).
http://bugs.winehq.org/show_bug.cgi?id=20204
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2010-05-19 11:41:26 --- I propose to close this bug unless it is renamed to "clipboard.ok sometimes fails (not only on 64bit)". Since my September patch got accepted last year, this bug lost its initial focus. Current results on test.winehq.org do not permit to identify enhanced metafile retrieval as the cause of the occasional failures and the randomness of results from 10 consecutive runs, mentioned in my previous comment, is gone. Current, repeatable state is: clipboard: 381 tests executed (1 marked as todo, 0 failures), 0 skipped.
http://bugs.winehq.org/show_bug.cgi?id=20204
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2010-05-21 14:39:31 --- Closing bugs fixed in 1.2-rc1.
http://bugs.winehq.org/show_bug.cgi?id=20204
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.5 |Mac OS X
-
wine-bugs＠winehq.org