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

Re: [3/3] ws2_32/tests: Get rid of the do_oob_send helper function

by Bruno Jesus

On Thu, Mar 6, 2014 at 7:46 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > OK... so i removed the Exit function and it works: > https://testbot.winehq.org/JobDetails.pl?Key=5449 > Now i'll test if it's the TlsFree, the WSACleanup or something else... I remember testing the TlsFree, I don't think it's that either.

March 6, 2014

Re: [3/3] ws2_32/tests: Get rid of the do_oob_send helper function

by André Hentschel

Am 06.03.2014 13:35, schrieb Bruno Jesus: > On Wed, Mar 5, 2014 at 10:24 PM, Marvin <testbot(a)winehq.org> wrote: >> === wvistau64 (64 bit sock) === >> sock: unhandled exception c0000005 at 000007FEFF0720C0 >> >> === w2008s64 (64 bit sock) === >> sock: unhandled exception c0000005 at 000007FEFE4220C0 > > It looks like the crashes are not related to WSACleanup then... I > don't have any idea then... Maybe valgrind can help finding a leak or > something like that. It didn't happen in the old testbot but I'm not > sure these Windows versions where present there. > > Regards, > Bruno > Yeah it crashes anyway when ending: https://testbot.winehq.org/JobDetails.pl?Key=5446 that seems odd... OK... so i removed the Exit function and it works: https://testbot.winehq.org/JobDetails.pl?Key=5449 Now i'll test if it's the TlsFree, the WSACleanup or something else...

March 6, 2014

Re: Wine test day #2: an easy lob

by Piotr Caban

On 3/6/14 7:55 PM, Henri Verbeet wrote: > On 6 March 2014 19:38, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> Unfortunately it doesn't work when ddraw tests are also executed. If so >> dinput8 still causes mouse messages to be not delivered. It's somehow >> related to windows still doing some work related to recent mode changes. >> This case starts working if I add a 1 second sleep after ddraw tests. I >> don't know what really happens here. >> > Is this caused by a specific ddraw test? I don't think it's actually related to ddraw tests. It's probably exposing some kind of race inside dinput8 tests. I was testing it with all tests disabled except ddrawmodes.

March 6, 2014

Re: Wine test day #2: an easy lob

by Henri Verbeet

On 6 March 2014 19:38, Piotr Caban <piotr.caban(a)gmail.com> wrote: > Unfortunately it doesn't work when ddraw tests are also executed. If so > dinput8 still causes mouse messages to be not delivered. It's somehow > related to windows still doing some work related to recent mode changes. > This case starts working if I add a 1 second sleep after ddraw tests. I > don't know what really happens here. > Is this caused by a specific ddraw test?

March 6, 2014

Re: [PATCH 1/5] wined3d: Decouple private data from the resource structure (try 5).

by Stefan Dösinger

Am 06.03.2014 um 18:58 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 6 March 2014 16:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> +static inline HRESULT wined3d_private_store_free_private_data(struct wined3d_private_store *store, const GUID *guid) >> +{ >> + struct wined3d_private_data *entry; >> + >> + entry = wined3d_private_store_get_private_data(store, guid); >> + if (!entry) >> + return WINED3DERR_NOTFOUND; >> + >> + if (entry->flags & WINED3DSPD_IUNKNOWN) >> + IUnknown_Release(entry->content.object); >> + else >> + HeapFree(GetProcessHeap(), 0, entry->content.data); >> + >> + list_remove(&entry->entry); >> + HeapFree(GetProcessHeap(), 0, entry); >> + >> + return WINED3D_OK; >> +} > I think it would make more sense to pass this a struct > wined3d_private_data pointer instead of a GUID. I prefer to keep it this way. The bigger the difference between the original resource API and these helper functions is the bigger the wrapper functions in each client dll become.

March 6, 2014

Re: Wine test day #2: an easy lob

by Piotr Caban

I'm still trying to find what's happening there. It's related to some strange state that ddraw and dinput8 tests leaves mouse in. What happens if dragdrop tests are executed just after dinput8 tests (and mouse is left above desktop): - dinput8 simulates mouse left button being pressed - this starts marquee selection on desktop (that is still in progress during dragdrop tests) - dragdrop is not receiving any mouse messages so it hangs (only desktop window is receiving mouse messages) I've tried adding a temporary window that receives the click. This lets this tests run successfully. Unfortunately it doesn't work when ddraw tests are also executed. If so dinput8 still causes mouse messages to be not delivered. It's somehow related to windows still doing some work related to recent mode changes. This case starts working if I add a 1 second sleep after ddraw tests. I don't know what really happens here. I'm attaching a work in progress patch for dinput8 tests. I'm slowly out of ideas how to proceed further. If anyone has any thoughts please let me know. Thanks, Piotr

March 6, 2014

Re: [PATCH 1/5] wined3d: Decouple private data from the resource structure (try 5).

by Henri Verbeet

On 6 March 2014 16:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static inline HRESULT wined3d_private_store_free_private_data(struct wined3d_private_store *store, const GUID *guid) > +{ > + struct wined3d_private_data *entry; > + > + entry = wined3d_private_store_get_private_data(store, guid); > + if (!entry) > + return WINED3DERR_NOTFOUND; > + > + if (entry->flags & WINED3DSPD_IUNKNOWN) > + IUnknown_Release(entry->content.object); > + else > + HeapFree(GetProcessHeap(), 0, entry->content.data); > + > + list_remove(&entry->entry); > + HeapFree(GetProcessHeap(), 0, entry); > + > + return WINED3D_OK; > +} I think it would make more sense to pass this a struct wined3d_private_data pointer instead of a GUID.

March 6, 2014

Wine test day #2: an easy lob

by Jeremy White

So it looks like the easy test for the day is drag/drop: http://test.winehq.org/data/tests/ole32:dragdrop.html Evidence suggests both that Piotr broke it, but is also working to fix it, so I don't think I get to shame him publicly...yet <grin>. Cheers, Jeremy

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > Would starting the service from taskschd.dll when an application calls >> > ITaskService::Connect() be a viable compromise? Of course that would mean >> > that the scheduled tasks will be added to the queue only when the service >> > is running. >> >> If there are scheduled tasks then it's OK for the service to be running >> always; but as long as there aren't, it should be started on-demand. > > So I would implement it like this: the service would be always started > on Wine boot, it would then load the xml task definitions and if there is > no anything would exit right away. Then the service would be started by > taskschd.dll if ITaskService::Connect() can't connect to an existing > service instance. Does this sound acceptable? No, having it start always defeats the whole point. Just mark it auto-start once a task is added. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > Would starting the service from taskschd.dll when an application calls > > ITaskService::Connect() be a viable compromise? Of course that would mean > > that the scheduled tasks will be added to the queue only when the service > > is running. > > If there are scheduled tasks then it's OK for the service to be running > always; but as long as there aren't, it should be started on-demand. So I would implement it like this: the service would be always started on Wine boot, it would then load the xml task definitions and if there is no anything would exit right away. Then the service would be started by taskschd.dll if ITaskService::Connect() can't connect to an existing service instance. Does this sound acceptable? -- Dmitry.

March 6, 2014