wine-devel September 2008

116 participants
274 discussions

Re: Patchwatcher: failed to apply: LookupAccountNameW() passes Expected SidTypeUser test

by Dan Kegel

Paul Bryan Roberts wrote: > This is the SECOND of a series of NINE patches ... When you send a series of 9 patches that depend on each other, please number them 1/9, 2/9, ... 7/9 in the subject line. Otherwise patchwatcher will try to apply each patch independently to current git, which won't work too well. Also, please make sure that tests still pass after each patch in the series. - Dan On Fri, Sep 26, 2008 at 4:06 AM, Patchwatcher <patchwatcher(a)kegel.com> wrote: > Hi! This is the experimental automated wine patchwatcher thingy. > The latest git sources were built and tested with your patch > "LookupAccountNameW() passes Expected SidTypeUser test" > Result: the patch failed to apply. > > You can retrieve the full build results at > http://kegel.com/wine/patchwatcher/results/2195.log > and see the patch as parsed at > http://kegel.com/wine/patchwatcher/results/2195.txt > See > http://kegel.com/wine/patchwatcher/results > for more info. > >

15 years, 7 months

Re: [3/5] secur32: Basic implementation of schannel AcquireCredentialsHandle/FreeCredentialsHandle

by Rob Shearman

2008/9/22 Henri Verbeet <hverbeet(a)gmail.com>: > +static ULONG_PTR schan_alloc_handle(void *object, enum schan_handle_type type) > +{ > + struct schan_handle *handle; > + > + if (schan_free_handles) > + { > + /* Use a free handle */ > + handle = schan_free_handles; > + if (handle->type != SCHAN_HANDLE_FREE) > + { > + ERR("Handle %d(%p) is in the free list, but has type %#x.\n", (handle-schan_handle_table), handle, handle->type); > + return -1; > + } Using a signed constant for an unsigned value isn't good practice. I'd recommend defining a constant at the top of the file like so: #define SCHANNEL_INVALID_HANDLE ~0UL And then using that everywhere that you use -1 now. -- Rob Shearman

15 years, 7 months

Flaky test update

by Dan Kegel

Here's some data over 1042 test runs over the last three weeks, all on a dual core Ubuntu 8.04 linux box with a cheap nVidia GeForce 8500 GT graphics card. Three tests crashed from 1% to 10% of the time (as opposed to failed): ddraw 136 d3d9 48 d3d8 12 Three tests always failed: urlmon:protocol.c 1042 dsound:ds3d8.c 1042 dsound:ds3d.c 1042 Two tests usually failed: user32:msg.c 940 user32:input.c 756 Nine tests failed from 0.1% to 20% of the time. (Even tests that only fail once in a thousand runs are bad, since they cause spurious patch failure reports. I've blacklisted all the tests listed here, which means patchwatcher *ignores* these tests, even if they have valid failures.) comctl32:tooltips.c 206 user32:win.c 205 riched20:editor.c 174 kernel32:thread.c 124 wininet:http.c 59 ddraw:visual.c 7 advapi32:service.c 7 kernel32:debugger.c 2 urlmon:url.c 1 Of those nine test, the following six had a fairly small number of characteristic error messages: comctl32:tooltips.c riched20:editor.c kernel32:thread.c advapi32:service.c kernel32:debugger.c urlmon:url.c And here are those error messages: 206 comctl32:tooltips.c:223: Test failed: CustomDraw run 0 stages 0, expected 1 174 riched20:editor.c:5322: Test failed: Cursor is at 0 instead of 4 174 riched20:editor.c:5328: Test failed: Cursor is at 4 instead of 9 174 riched20:editor.c:5334: Test failed: Cursor is at 0 instead of 4 20 kernel32:thread.c:1181: Test failed: WaitForMultipleObjects failed 4 kernel32:thread.c:1181: Test failedthread.c:130: Test failed: WaitForSingleObject failed 4 kernel32:thread.c:1181: Test failedthread.c:144: Test failed: WaitForSingleObject failed 17 kernel32:thread.c:1184: Test failed: WaitForMultipleObjects failed 8 kernel32:thread.c:1184: Test failed: thread.c:144: Test failed: WaitForSingleObject failed 22 kernel32:thread.c:1186: Test failed: WaitForMultipleObjects failed 11 kernel32:thread.c:1186: Test failed: thread.c:144: Test failed: WaitForSingleObject failed 120 kernel32:thread.c:130: Test failed: WaitForSingleObject failed 1 kernel32:thread.c:130: Test failedthread.c:1181: Test failed: : WaitForSingleObject failed 134 kernel32:thread.c:144: Test failed: WaitForSingleObject failed 6 advapi32:service.c:2032: Test failed: Expected success 7 advapi32:service.c:2043: Test failed: Expected success 7 advapi32:service.c:2047: Test failed: Expected success 2 kernel32:debugger.c:300: Test failed: exit code = 00000000 1 urlmon:url.c:2125: Test succeeded inside todo block: unexpected OnProgress_CONNECTING 1 urlmon:url.c:2129: Test failed: expected OnProgress_SENDINGREQUEST 1 urlmon:url.c:2131: Test failed: expected OnResponse All the data is online at http://kegel.com/wine/patchwatcher/results if you want to look for details. - Dan

15 years, 7 months

Re: [4/5] secur32: Allocate schannel client credentials

by Rob Shearman

2008/9/22 Henri Verbeet <hverbeet(a)gmail.com>: > @@ -47,6 +61,7 @@ struct schan_handle > struct schan_credentials > { > ULONG credential_use; > + gnutls_certificate_credentials_t credentials; > }; > > static struct schan_handle *schan_handle_table; > @@ -273,6 +288,7 @@ static SECURITY_STATUS schan_AcquireClientCredentials(const SCHANNEL_CRED *schan > } > > creds->credential_use = SECPKG_CRED_OUTBOUND; > + pgnutls_certificate_allocate_credentials(&creds->credentials); > > phCredential->dwLower = handle; > phCredential->dwUpper = 0; You should check the return value from gnutls_certificate_allocate_credentials, in case it fails and return a failure code to the caller. -- Rob Shearman

15 years, 8 months

Re: [2/2] oleacc: implemented GetRoleText[A/W] with some tests

by Alexandre Julliard

Nikolay Sivov <bunglehead(a)gmail.com> writes: > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletext; > + INT ret; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + > + if(!length || !lpRole) > + return length; You can't return the W length from the A function. > + roletext = HeapAlloc(GetProcessHeap(), 0, (length + 1)*sizeof(WCHAR)); > + if(!roletext) > + return 0; > + > + GetRoleTextW(role, roletext, length + 1); > + > + ret = WideCharToMultiByte( CP_ACP, 0, roletext, -1, lpRole, rolemax, NULL, NULL ); This won't return the correct length. Also you need to test how overflow should be handled. -- Alexandre Julliard julliard(a)winehq.org

15 years, 8 months

re: comctl32: comboex - fix some unintialized variables

by Dan Kegel

You wrote: > Fixes a compiler bug when using gcc-4.1 Wait- which is it, uninitialized variables (as your subject line said), or a compiler bug (as your message said)? If it's a compiler bug, which one? Probably http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639, right? Would setting the fields to any random value work as well? Can we instead tell the compiler to avoid the bug? (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9049 says there's no way yet to turn warnings on and off for individual functions, sadly, but we can do it for individual files.) A link to the bug report at gcc.gnu.org, and/or a wine wiki page about the general issue, would be helpful.

15 years, 8 months

Re: msi: add stub for MsiDetermineApplicablePatches{A,W} (resend)

by James Hawkins

On Thu, Sep 25, 2008 at 2:10 AM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Resend: removed spaces around brackets, and added also A-version. > > +/*********************************************************************** + * * MsiDetermineApplicablePatchesA [MSI.@] + * */ Copy/paste error? -- James Hawkins

15 years, 8 months

Re: msi: add stub for MsiDetermineApplicablePatchesW

by Louis. Lenders

----- Original Message ---- From: James Hawkins <truiken(a)gmail.com> >The vast majority of this file does not put spaces around parenthesis, >so can you resend with that fixed? well, the last functions from that file do put the spaces around them, but if you prefer otherwise, i'll resend it >Also, why don't you add MsiDetermineApplicablePatchesA at the same time? i tried to keep patch as small as possible, and this is enough to fix the bug, but i'll add the A-version along the way in the resend. James Hawkins

15 years, 8 months

Re: [2/2] oleacc: implemented GetRoleText[A/W] with some tests

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletext; > + INT ret; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + > + if(!length || !lpRole) > + return length; This won't work for a multibyte locale. -- Dmitry.

15 years, 8 months

RE: [5/5] wined3d: Handle texture coordinates the same way we handle other vertex attributes

by Stefan Dösinger

Here's a thought regarding handling the lack of GL_ARB_multitexture support. Since pretty much all cards out there have multitexture support(even my junky Mach64 card), we could just use one texcoord function array, and if multitextures are really not supported, use a wrapper function that calls the non-multitexture gl function and just drops the texture unit. That avoids the if check in this pretty performance critical part on probably all cards out there that are in use. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Wednesday, September 24, 2008 9:14 AM > To: wine-patches(a)winehq.org > Subject: [5/5] wined3d: Handle texture coordinates the same way we > handle other vertex attributes >

15 years, 8 months

← Newer
1
2
3
4
5
6
7
8
9
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2008