October 2009 - Wine-Devel - list.winehq.org

Re: [PATCH 01/12] d3d10: Fix a HeapFree() in d3d10_effect_Release().

by Henri Verbeet

2009/10/28 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Do we have any tests for the As* behavior? > > Most conversions don't make any sense, so if the app wants a constant buffer > as a render target view returning a null obj is probably a sane thing. But > ::AsString potentially makes sense for all objects, maybe in a similar way > Object::ToString is used to obtain a String for debug output in Java. > > Also, do we know what happens if the object is "converted" back to its > original state? E.g. > > constant_buffer = render_target_view::AsConstantBuffer(); > render_target_view2 = constantBuffer::AsRenderTargetView? > > As far as I understand it, your code would return a null rt view. Is this > correct? > The patches are correct, I wrote tests for this for commits 508635ac4c290b00bd2aa97026e627a50d3c4cee, 58fcb06c07cbe4fd9cd94dc138d625cf08b82fb7 and fbbbdc09a591d7e8deae3830400ac7ad1d2fca8e. I didn't submit those though.

Oct. 28, 2009

Re: [PATCH 01/12] d3d10: Fix a HeapFree() in d3d10_effect_Release().

by Stefan Dösinger

Am 27.10.2009 um 20:10 schrieb Rico Schüller: > Hi, > > this patch series implements a couple of ID3D10EffectVariable::As*() > functions (patches 2-11). Do we have any tests for the As* behavior? Most conversions don't make any sense, so if the app wants a constant buffer as a render target view returning a null obj is probably a sane thing. But ::AsString potentially makes sense for all objects, maybe in a similar way Object::ToString is used to obtain a String for debug output in Java. Also, do we know what happens if the object is "converted" back to its original state? E.g. constant_buffer = render_target_view::AsConstantBuffer(); render_target_view2 = constantBuffer::AsRenderTargetView? As far as I understand it, your code would return a null rt view. Is this correct?

Oct. 28, 2009

Re: Extracting yet more wine tests from the chromium test suite

by Dan Kegel

Oh, I've also updated http://wiki.winehq.org/UnitTestSuites to reflect this progress.

Oct. 28, 2009

Re: for the record, my ole32 binary tree search patch is correct

by Yuriy Kaminskiy

On 27.10.2009 22:50, Vincent Povirk wrote: > I sent the following patch recently: > > commit ee6856d874d687c4504914e61bcde3e6b8823bca > Author: Vincent Povirk <madewokherd(a)gmail.com> > Date: Fri Oct 23 13:57:42 2009 -0500 > > ole32: Don't use IEnumSTATSTG to search for elements of storages. > > We use it to do a linear search of a binary tree, which is overkill. > Replace it with a simple binary search. > > It was accepted and caused this bug: > http://bugs.winehq.org/show_bug.cgi?id=20477 > > It actually turned out that the mistake was in a previous patch, but > it didn't matter for reading files until we started to depend on the > tree to be valid. Nonetheless, I've done a test to make sure we can > really rely on the binary trees in storage files to be valid. > [...] > This means that Windows does depend on the tree in a storage file to > be correct, and Wine's behavior is now closer to Windows, even though > it now fails in some cases when it used to succeed. If I've not mistaken, that uses lstricmp internally for comparing keys. Note, that wine lstr[i]cmp and ms windows lstr[i]cmp uses different sort order (see last [disabled] test in dlls/kernel32/tests/locale.c). So binary search using wine lstricmp on presored array (used windows lstricmp) will certainly fail on some files. PS looking at code one more time, current code seems already depends on "lstricmp working same" [in updatePropertyChain()], so already broken. It's pure luck that it is not failed already. Disclaimer: I'm not expert in wine code, looked at code very quickly, and may be misread something :-\

Oct. 28, 2009

Extracting yet more wine tests from the chromium test suite

by Dan Kegel

http://kegel.com/wine/chromium/ now has a precompiled tarball containing 13 of chromium's test programs: app_unittests base_unittests courgette_unittests googleurl_unittests ipc_tests media_unittests net_unittests printing_unittests sbox_unittests sbox_validation_tests setup_unittests tcmalloc_unittests unit_tests (These are, more or less, all the ones that run in under a minute on Windows. There are some big tests left, but I figured this was enough to chew on for a while.) http://kegel.com/wine/chromium/failures.txt lists the 50 test cases which fail (but not crash) in which executable. http://kegel.com/wine/chromium/chromium-runtests.sh.txt has a little documentation, and shows how to skip the handful of tests that crash or hang. I'm slowly starting to file bugs and/or testcases for these, starting with http://bugs.winehq.org/show_bug.cgi?id=20495. (It took me a while to do that one today - writing the wine test case was easy, but figuring out why it passed but the real test didn't required pulling out the important part of the logs for both and flipping back and forth between them in an editor. Once I did that, it was trivial.) I don't actually expect the sandbox tests to work any time soon, but they're there if anyone's interested. - Dan

Oct. 28, 2009

Re: [1/2] shell32/tests: Program Manager DDE Conformance Tests

by Vitaliy Margolen

Mike wrote: > Conformance Tests to test the Program Manager DDE. Currently stubbed in Wine, bug 9159. Has been tested on Win XP SP2 and Win 98 SE. > > --- > dlls/shell32/tests/Makefile.in | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/shell32/tests/Makefile.in b/dlls/shell32/tests/Makefile.in > index dd0587c..0cad860 100644 > --- a/dlls/shell32/tests/Makefile.in > +++ b/dlls/shell32/tests/Makefile.in > @@ -9,6 +9,7 @@ CTESTS = \ > appbar.c \ > autocomplete.c \ > generated.c \ > + progman_dde.c \ > shelllink.c \ > shellpath.c \ > shfldr_special.c \ > -- This can't work on it's own and should be merged with your next patch. > +HDDEDATA CALLBACK DdeCallback(UINT type, > + UINT format, > + HCONV hConv, > + HSZ hsz1, > + HSZ hsz2, > + HDDEDATA hDDEData, > + ULONG_PTR data1, > + ULONG_PTR data2) > +{ > + trace("Callback: type=%i, format=%i\n", type, format); > + return NULL; > +} > + Tabs should always be set to 8 spaces, not 4. For Wine please use 4-space indentations, no tabs please. > +int IsWin9x(void) > +{ > + return (GetVersion() & 0x80000000); > +} Don't add this sort of functions. All tests should work on all Windows versions. Or you should detect differences by other means. > +/* Transfer DMLERR's into text readable strings for Error Messages */ > +const char * GetStringFromError(UINT err) > +{ > + const char * retstr; > + switch (err) > + { > + case DMLERR_NO_ERROR: > + retstr = "DMLERR_NO_ERROR"; > + break; > + case DMLERR_ADVACKTIMEOUT: > + retstr = "DMLERR_ADVACKTIMEOUT"; > + break; > + case DMLERR_BUSY: Use ## macro for this instead. See examples throughout the code-base. > + window = FindWindow(NULL, winName); > + SendMessage(window, WM_SYSCOMMAND, SC_CLOSE, 0); You should explicitly specify A or W variant of the function in tests. > + path = (char *) malloc(MAX_PATH); Don't use malloc in tests, use HeapAllock instead. > + DdeExecuteCommand(instance, hConv, (char *) "[InvalidCommand()]", &hData, &error, DDE_TEST_MISC|testnum++); This is wrong - don't cast away const pointers. If you getting warnings that means you doing something wrong. Vitaliy.

Oct. 28, 2009

for the record, my ole32 binary tree search patch is correct

by Vincent Povirk

I sent the following patch recently: commit ee6856d874d687c4504914e61bcde3e6b8823bca Author: Vincent Povirk <madewokherd(a)gmail.com> Date: Fri Oct 23 13:57:42 2009 -0500 ole32: Don't use IEnumSTATSTG to search for elements of storages. We use it to do a linear search of a binary tree, which is overkill. Replace it with a simple binary search. It was accepted and caused this bug: http://bugs.winehq.org/show_bug.cgi?id=20477 It actually turned out that the mistake was in a previous patch, but it didn't matter for reading files until we started to depend on the tree to be valid. Nonetheless, I've done a test to make sure we can really rely on the binary trees in storage files to be valid. I wrote two programs: one that reads the directory entries of a storage file and prints some information to stdout (useful for debugging), and one that swaps the left and right child of every directory entry, corrupting the trees in the file. It turns out that corrupting an msi file in this way makes it fail on both windows and on wine (although it crashes on wine; msi's error handling code is broken). Running the program again (thus swapping the children back to their original, correct position) makes it work. However, on an older version of Wine without my change, the corrupted msi file loads fine. This means that Windows does depend on the tree in a storage file to be correct, and Wine's behavior is now closer to Windows, even though it now fails in some cases when it used to succeed. (I think that current Wine without the fix for bug 20477 will load only the corrupted files, but I didn't test this.) I've attached my test programs so they're in the public record. -- Vincent Povirk

Oct. 27, 2009

Re: d3d10: Parse local_variables.

by Rico Schüller

Am 27.10.2009 05:14, schrieb Dan Kegel: > (Spotted by http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-d3d10_effect.txt > ) > > Hi Rico, > the patch > > commit b55641f14a210f689cde8b08750a78779657c06e > Author: Rico Schüller<kgbricola(a)web.de> > Date: Sun Oct 25 17:11:49 2009 +0100 > > d3d10: Parse local_variables. > > seems to have introduced the following valgrind error: > > http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-d3d10_effect.txt > > Invalid free() / delete / delete[] > at notify_free (heap.c:222) > by RtlFreeHeap (heap.c:1474) > by d3d10_effect_Release (effect.c:1649) > by test_effect_constant_buffer_type (effect.c:193) > by func_effect (effect.c:1128) > by run_test (test.h:535) > by main (test.h:585) > Address 0x7f03def0 is 104 bytes inside a block of size 112 alloc'd > at notify_alloc (heap.c:214) > by RtlAllocateHeap (heap.c:1421) > by D3D10CreateEffectFromMemory (d3d10_main.c:218) > by test_effect_constant_buffer_type (effect.c:93) > by func_effect (effect.c:1128) > by run_test (test.h:535) > by main (test.h:585) > > and a number of small leaks of the form > > 0 bytes in 1 blocks are definitely lost > at notify_alloc (heap.c:214) > by RtlAllocateHeap (heap.c:1421) > by parse_fx10_body (effect.c:1280) > by parse_fx10 (effect.c:1394) > by fx10_chunk_handler (effect.c:1408) > by parse_dxbc (effect.c:157) > by d3d10_effect_parse (effect.c:1418) > by D3D10CreateEffectFromMemory (d3d10_main.c:230) > by test_effect_variable_element (effect.c:665) > by func_effect (effect.c:1131) > by run_test (test.h:535) > by main (test.h:585) > > Could you have a look? > > Thanks, > Dan > > Hi Dan, the HeapFree() call is wrong in this patch, I'll send a fix for that. Thanks for the hint. Cheers Rico

Oct. 27, 2009

[RFC] mshtml/tests: Fix events test when pointer is on a corner.

by Nicolas Le Cam

Hi, Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having errors on events tests. I just found that it only fails if pointer is on any corner. As I'm always putting it on upper right corner when running winetest it was always failing for me. Minimizing the test window fixed it for me but I'm not sure it's the right fix, so I'm sending it to wine-devel. Tested on Win2k SP4 and WinXP SP2 (both with IE6). -- Nicolas Le Cam

Oct. 27, 2009

New DOS drives handling patchset: testers wanted

by Charles Davis

Hi, Attached is my latest attempt at moving DOS drive handling completely over to mountmgr. You might remember my last patchset that tried this. That patchset was a real piece of crap. I tested it, and there were compile warnings, crashes, and mysterious "dangling FD object" problems that I'd rather avoid. I fixed all of those, and I must say that this is a vast improvement over that early attempt. But since this is such a major change, I want to make sure I have this absolutely right before I send it in. That's why I need people to test this for me, and report any problems, failed tests, etc. It works on my system, so it just might work on yours. Enjoy. Chip

Oct. 27, 2009