February 2014 - Wine-Devel - list.winehq.org

Re: Use of wined3d_mutex?

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-26 20:13, schrieb Max TenEyck Woodbury: > In particular, user call back functions are being called in > several places with this mutex held. If the callback starts > another thread to do something graphical where the thread needs the > mutex, and then waits for the thread to finish, both threads will > hang until the mutex times out. There are also places where a > function that takes out the mutex is called with the mutex already > held. ddraw calls application-provided callback functions. A long time ago I did some testing on Windows, and it also uses a dll-global lock for ddraw and keeps it held when calling those callbacks. So we're doing the right thing here. In case of d3d8/9, there are in theory the Resource's SetPrivateData, GetPrivateData and FreePrivateData functions that can call application code, specificly an IUnknown's AddRef and Release function. I have never tested how those behave wrt the dll lock. This thing can also be used to write a black-box test to see at which granularity Windows does d3d8/9 synchronization. > Switching to another terminal window and back again sometimes > breaks these deadlocks. That seems wrong, unless we're accidentally holding those locks while sending window messages. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTDvMPAAoJEN0/YqbEcdMwg0kP/0VGijPb4vGV9iFAcYdA7P0j GGapgcXy8Iv5Mpf3aJodEK6awCB5aVYfTC90Qr1ys04WJSQqvN+GDL4+fu9189hf sO+pK2kXlPmpmPjTwisqiT31BZ+wAN+7llPbJXpTkMw6xwKl+lxq9jm81FUmNT5S 0zFhEFCwbrPfydHNKp9/5vUpFTZ4dt7vycUg7Be7ujqUnr+JKo9SGiOz5eDE3E9R CIR03JTg0wQitiekxcdbhSQ0K/mIg857WzCTWa+Lc0r/bij6Ebf6NQPI+oobbOJI 9GbeFhwcKtLppO6B075F82j07jyLiNVC+k19UtW4Dby0gLeOI458smcEy8zUVEk5 Rfwgbej7xpHirWpMOgy0B0UtIH1HQkMs8dTKa5XfyZGLyVkoj+wnsf1PXCIVbphZ VvCt6htV0PgDzlYMOpMaja0/yebfscRnY1nCHOdaYMtTMoGAfclRK/yMdVR8Q5tO joEqAMtG20NcpbIPgRc/ZFFj5S7lZH+NTdd5MYxy1CmC7+AZ3XrSShfSFzFSS0Z5 KrHGQ0Z28DbFdWOBlVZOfe38ffj82On++cRzKTyChLBU+g80ZRzfPJMQ+ZEdu9qz AY+inhWRfs84XM1GupRgxU0Jlih10KoXiVCTVzlMJDIQY8/Efd8dD3b7ewXRgsV3 GVQxXjBp2XqhGRaqcZPr =+HPs -----END PGP SIGNATURE-----

Feb. 27, 2014

Re: [PATCH] taskschd: Create dummy task definition for GetTask()

by Nikolay Sivov

On 2/27/2014 11:49, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> RegisteredTask_create() doesn't handle NULL definition, >> neither does IRegisteredTask code. If it's meant to be fixed differently >> please let me know. > This still needs a lot of work, there is no need to pitch in. > Oh yeah, I need it, it crashes for me.

Feb. 27, 2014

Re: [PATCH] taskschd: Create dummy task definition for GetTask()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > RegisteredTask_create() doesn't handle NULL definition, > neither does IRegisteredTask code. If it's meant to be fixed differently > please let me know. This still needs a lot of work, there is no need to pitch in. -- Dmitry.

Feb. 27, 2014

Re: [PATCH] oleaut32: Implement DISPID_PICT_RENDER dispid (try3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5216 Your paranoid android. === wvistau64 (64 bit olepicture) === olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000 olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000 === w2008s64 (64 bit olepicture) === olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000 olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000 === w7pro64 (64 bit olepicture) === olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000 olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x800a017c olepicture.c:646: Test failed: DISPID_PICT_RENDER returned wrong code, 0x80020005, expected 0x00000000

Feb. 27, 2014

Re: [2/2] ws2_32: Add WSAEnumNameSpaceProviders[A|W] implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5214 Your paranoid android. === build (build) === Make failed

Feb. 27, 2014

Re: [1/2] ws2_32/tests: Add WSAEnumNameSpaceProviders[A|W] tests (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5213 Your paranoid android. === build (build) === Make failed

Feb. 27, 2014

Use of wined3d_mutex?

by Max Woodbury

I have been looking at the use of the wined3d_mutex_lock and wined3d_mutex_unlock functions in the drawing code. I strongly suspect that it is being badly over-used. In particular, user call back functions are being called in several places with this mutex held. If the callback starts another thread to do something graphical where the thread needs the mutex, and then waits for the thread to finish, both threads will hang until the mutex times out. There are also places where a function that takes out the mutex is called with the mutex already held. Switching to another terminal window and back again sometimes breaks these deadlocks. It used to be that I had to do this several times doing a 'make test', but it just takes a long time now. (Yes, years ago I left the test running for several hours when I went out for a few hours and it was still hung when I got back. That does not happen now,) This shows up running Guild Wars 2. I have a CPU monitor running while I play and I can see the game chomping on both cores, except that the game will sometimes hang for 30-45 seconds and then resume. I am in the process of annotating the drawing routines use of the mutex, and there is simply a lot of code to go through. Could someone with a good understanding of the drawing part of wine comment please. In particular, are there places where the lock-like action of the reference counts can be used in place of taking out the mutex? max

Feb. 27, 2014

Re: [PATCH 2/2] Quickly retry sendmsg or recvmsg if errno is EAGAIN or EINTR.

by Max Woodbury

On 02/26/2014 08:32 PM, Erich E. Hoover wrote: > On Wed, Feb 26, 2014 at 6:10 PM, Max Woodbury <mtewoodbury(a)gmail.com> wrote: >> ... >> So it's mainly on style: >> >> - I've been reading other peoples code for 50 years and that aspect >> of K&R is much easier to handle in my opinion. Same with the >> extra blank line. Other parts of wine use the style and are much >> easier to read as a result. >> >> - And the miscount can't simply be ignored? > > Very little of Wine uses a blank line after an if, and I've never seen > it with a single line statement. That doesn't really matter though, > the rest of the function (and really the whole file) is in Allman > style and our current guidelines require matching the surrounding > style. (Note: I am not in charge of this, so debating me on the topic > is pointless) > Bluntly Allman style sucks. It is just plain hard to read. Also, the blank line is associated with the 'return' and is often used. >> If you read kernel code, you'll find that just returning to >> application level is sometimes enough to free the missing resource. >> That happens often enough that a single quick retry on EAGAIN is >> warranted. > > I'm not familiar enough with what you're trying to do, but if the > buffer is full and the kernel throws back EAGAIN then it would seem > that you're not in such a time crunch that waiting for the higher > level to handle it is going to be a problem. I could be wrong though, > I don't do a lot of high-throughput socket programming. > Not a buffers full problem. Internal locks that get released from a thread switch and things like that. Worth ONE retry to see if they clear. If its still stuck on the second attempt, punt. And it's not me, it's the game... >> Bringing the relevant part of the retry code down and applying it to >> only those parts where is has a strong likelihood of doing the most >> good is exactly what the patch does. If one retry is not enough, then >> higher level strategy is needed so no changes are called for on the >> higher level. A loop at this level is _not_ a good idea since there >> would have to be something to break the loop if it runs too long. > > I believe that Ken was suggesting that there are ways to do this such > that the higher level can handle EGAIN and the lower level EINTR. In > my, admittedly limited, experience with this issue his suggestion > seems reasonable, but I could be wrong. However, I am sure that if > you put together a convincing test case that it will make getting the > patch accepted a lot easier (though not guaranteed). > TEST CASE?!? Not! Multi-thread with graphics throwing interrupts left and right! Disk interrupts. Real internet delays. Instead, just watch the game with the problem for a day or two. Better read a few good Unix programming text. Ask the impossible why dont'cha. >> In other words, this fiddle is based on several decades of experience with >> kernel and bottom level application debugging experience. At >> least look at it and test it before rejecting it on superficial grounds. > > Please do not be confused, I am not in charge of acceptance/rejection. > I have, however, been involved in Wine long enough to know that if > you don't address the issues mentioned on this list (either with an > explanation, the addition of new tests, or changing the code to handle > the case mentioned) then AJ will usually reject the patch. > Yep. If it were possible, I'd do just that, but it's not... On the other hand, forgetting a CC is bad. (Fixed. Want to compare years on the list? I've a few...) > Best, > Erich

Feb. 27, 2014

Re: ddraw/tests: Probe the supported display modes and skip tests based on the result.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5210 Your paranoid android. === w2000pro (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00426DB5 === w8 (32 bit ddraw2) === ddraw2.c:5278: Test failed: Got unexpected refcount 3. ddraw2.c:5297: Test failed: Got unexpected refcount 3. ddraw2.c:5304: Test failed: Got unexpected hr 0. ddraw2.c:5307: Test failed: Got unexpected refcount 3. ddraw2.c:5309: Test failed: Got unexpected refcount 2. ddraw2.c:5315: Test failed: Got unexpected hr 0. ddraw2.c:5318: Test failed: Got unexpected refcount 2. ddraw2.c:5320: Test failed: Got unexpected refcount 1. No test summary line found Failure running script in VM: network read timed out === w8 (32 bit ddraw1) === ddraw1.c:4182: Test failed: Got unexpected refcount 3. ddraw1.c:4201: Test failed: Got unexpected refcount 3. ddraw1.c:4208: Test failed: Got unexpected hr 0. ddraw1.c:4211: Test failed: Got unexpected refcount 3. ddraw1.c:4213: Test failed: Got unexpected refcount 2. ddraw1.c:4219: Test failed: Got unexpected hr 0. ddraw1.c:4222: Test failed: Got unexpected refcount 2. ddraw1.c:4224: Test failed: Got unexpected refcount 1. === w2000pro (32 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0045C558 === w8 (32 bit ddraw7) === Failure running script in VM: network read timed out === w2000pro (32 bit ddraw4) === ddraw4: unhandled exception c0000005 at 00441995 === w8 (32 bit ddraw4) === ddraw4.c:5874: Test failed: Got unexpected refcount 3. ddraw4.c:5893: Test failed: Got unexpected refcount 3. ddraw4.c:5900: Test failed: Got unexpected hr 0. ddraw4.c:5903: Test failed: Got unexpected refcount 3. ddraw4.c:5905: Test failed: Got unexpected refcount 2. ddraw4.c:5911: Test failed: Got unexpected hr 0. ddraw4.c:5914: Test failed: Got unexpected refcount 2. ddraw4.c:5916: Test failed: Got unexpected refcount 1. ddraw4.c:5918: Test failed: Got unexpected refcount 6. Timeout Failure running script in VM: network read timed out

Feb. 27, 2014

Re: d3d9/tests: Fix some test failures on Windows 2000.

by Francois Gouget

On Tue, 25 Feb 2014, Henri Verbeet wrote: > On 24 February 2014 23:54, Francois Gouget <fgouget(a)codeweavers.com> wrote: > > --- > > > > This fixes some tests on the WineTestBot VM. > > > > dlls/d3d9/tests/device.c | 18 +++++++++--------- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > > Most of the IDirect3D9_CreateDevice() calls in device.c should be > calls to create_device() instead. (And then just skip() if it fails to > create a device.) I think the only exceptions are test_fpu_setup() and > test_swvp_buffer(). The remaining CreateDevice() calls seem to be using pretty different parameters. For instance in test_mipmap_levels() it uses a different backbuffer format, does not set its size, sets EnableAutoDepthStencil to FALSE and passes D3DDEVTYPE_NULLREF. Will the test really still make sense if all that is changed? Another example is test_depthstenciltest() which sets EnableAutoDepthStencil to FALSE but still sets AutoDepthStencilFormat. That's different from create_device() and intentionally so. (test_reset() does so once too without a comment which looks more questionable) The problem is there's about 20 remaining CreateDevice() calls and I would be hard pressed to tell if they are crucially different from what create_device() does. -- Francois Gouget <fgouget(a)codeweavers.com>

Feb. 27, 2014