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

Re: [3/8] crypt32: Remove unused variable and avoid a memory leak on error path.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/crypt32/filestore.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/crypt32/filestore.c b/dlls/crypt32/filestore.c > index 44b9bbb..6084395 100644 > --- a/dlls/crypt32/filestore.c > +++ b/dlls/crypt32/filestore.c > @@ -117,9 +117,8 @@ static BOOL CRYPT_ReadBlobFromFile(HANDLE file, PCERT_BLOB blob) > blob->pbData = CryptMemAlloc(blob->cbData); > if (blob->pbData) > { > - DWORD read; > - > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); > + if (!ret) CryptMemFree(blob->pbData); In general if the read size is not checked that's a bug. -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2013

[3/8] crypt32: Remove unused variable and avoid a memory leak on error path.

by Thomas Faber

Hi, On 2013-10-28 09:28, Dmitry Timoshkov wrote: > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); the lpNumberOfBytesRead parameter is not optional on Windows for synchronous I/O, so could you keep it please? I've had to add it back in elsewhere to prevent Wine functions from crashing on Win. Thanks! Best, Thomas

Oct. 28, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

Henri Verbeet <hverbeet(a)gmail.com> writes: >> I've had a look at the logs and as far as I can tell, the failing test >> is not exercising the change I made. If anyone can shed some light on >> this, I'd be happy to resubmit the patch with the improved test failure >> reporting. >> > I think that's from test_rtpatch() that Stefan removed in > 9c19266a247a2f4e1f88a3258026af33c6cd6efc. I think all this patch needs > is to fix the warnings, and the improved failure messages. Looks like it wasn't that: https://newtestbot.winehq.org/JobDetails.pl?Key=3077&log_204=1#k204 Based on this "device.c:6759: this is the last test seen before the exception" it'd be somewhere within test_update_volumetexture or something after that. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 28, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeds (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=3077 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

Oct. 28, 2013

Re: msvcrt: add support for _chsize_s (try #3)

by Piotr Caban

Hi, On 10/26/13 04:58, Mike Koss wrote: > This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. > Incorporates previous feedback and now includes an updated test file. > > --- > dlls/msvcr100/msvcr100.spec | 2 +- > dlls/msvcr110/msvcr110.spec | 2 +- > dlls/msvcr80/msvcr80.spec | 2 +- > dlls/msvcr90/msvcr90.spec | 2 +- > dlls/msvcrt/file.c | 63 > +++++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/tests/file.c | 37 ++++++++++++++++++++++++++ > 7 files changed, 105 insertions(+), 5 deletions(-) There're few more issues with this patch: - _chsize_s is not defined in headers (please make sure that your code compiles without warnings) - _chsize_s is not available in some versions of msvcrt.dll, you should load it using GetProcAddress like in other *_s functions tests - the tests are failing on windows, it's probably also caused by lack of _chsize_s header Thanks, Piotr

Oct. 28, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 27 October 2013 14:22, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > Marvin <testbot(a)winehq.org> writes: > >> Full results can be found at >> https://newtestbot.winehq.org/JobDetails.pl?Key=2909 >> [...] >> === w864 (32 bit device) === >> device: unhandled exception c0000005 at 740D14C8 >> >> === w864 (64 bit device) === >> device: unhandled exception c0000005 at 000007F84EDD90EB > > I've had a look at the logs and as far as I can tell, the failing test > is not exercising the change I made. If anyone can shed some light on > this, I'd be happy to resubmit the patch with the improved test failure > reporting. > I think that's from test_rtpatch() that Stefan removed in 9c19266a247a2f4e1f88a3258026af33c6cd6efc. I think all this patch needs is to fix the warnings, and the improved failure messages.

Oct. 28, 2013

Re: [PATCH] wined3d: Use GL_ARB_texture_mirror_clamp_to_edge when available.

by Henri Verbeet

On 26 October 2013 22:23, Rico Schüller <kgbricola(a)web.de> wrote: > Well, I did a small update for the script (it may need some > improvements...). Please see the attached patch for make_opengl. I have > several questions to this: I didn't review the code very closely, but at first sight it looks like you have a couple of unrelated and whitespace only changes that should probably be in separate patches. I think there are also e.g. some comments that should be updated / removed. I can try to answer some of the questions, but ultimately it's up to Alexandre. > 1. Is it the correct way to just change the script or do we prefer > another way? Seems fine to me. Although it's a bit annoying that Khronos doesn't seem to want to make any guarantees about the stability of the XML format. > 2. Is it fine to use XML::Simple as a dependency? I think so, but I also think it's common to just put things like "use XML::Simple;" at the top of the file. > 3. Do we need to support gles functions and enums? Not initially, but we may want to in the future. > 4. Why was $pseudo_to_opengl used in the script? For mapping type. E.g. in gl.spec, ClearColor() takes 4 parameters of "ColorF", which is mapped to GLfloat in gl.tm. In the XML files that information is available as the "group" attribute, but we don't need it for our purposes. (See also https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/readme.…)

Oct. 28, 2013

Re: [PATCH 1/4] comctl32: Set updown control value to min or max in out of range case

by Piotr Caban

On 10/28/13 09:35, Alistair Leslie-Hughes wrote: > On 17/10/2013 1:34 AM, Piotr Caban wrote: >> --- >> dlls/comctl32/updown.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> - } else return FALSE; >> + } if ((infoPtr->MaxVal > infoPtr->MinVal && >> infoPtr->CurVal+delta > infoPtr->MaxVal) > ^^^ >> + || (infoPtr->MaxVal < infoPtr->MinVal && >> infoPtr->CurVal+delta < infoPtr->MaxVal)) { >> + delta = infoPtr->MaxVal - infoPtr->CurVal; > > Should the "if" be one its own line or was the else missed? The 'else' was missed. I've sent a fix for it. Thanks, Piotr

Oct. 28, 2013

Re: kernel32/tests: Update trace message to report actually used timeout value.

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=3074 Your paranoid android. === w2008s64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1551: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1518: Changing CommMask on the fly for handle 000000C4 after timeout 500

Oct. 28, 2013

Re: WineTestBot status update

by Francois Gouget

On Mon, 28 Oct 2013, Dmitry Timoshkov wrote: [...] > When next time I'll be playing with the tests what additional info could > I provide for better diagnosing the problem? I think the simplest would be to save the TestBot's home page and your Job's page as HTML files and send those. -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 28, 2013