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

Re: [6/7] gdi32/tests: Add tests for vertical writing metrics.
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3981 Your paranoid android. === wxppro (32 bit font) === font.c:1329: Test failed: got 8, expected 7 === wvista (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w2008s64 (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w7pro64 (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w2008s64 (64 bit font) === font.c:1330: Test failed: got 1, expected 0 === w7pro64 (64 bit font) === font.c:1330: Test failed: got 1, expected 0

1 0

Re: [5/7] gdi32: Fix ABC metrics for rotated font.
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3980 Your paranoid android. === wxppro (32 bit font) === font.c:1329: Test failed: got 8, expected 7 === wvista (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w2008s64 (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w7pro64 (32 bit font) === font.c:1330: Test failed: got 1, expected 0 === w2008s64 (64 bit font) === font.c:1330: Test failed: got 1, expected 0 === w7pro64 (64 bit font) === font.c:1330: Test failed: got 1, expected 0

1 0

Re: [4/7] gdi32/tests: Add more GetCharABCWidths tests for rotated font.
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3979 Your paranoid android. === wxppro (32 bit font) === font.c:1330: Test failed: got 8, expected 7 === wvista (32 bit font) === font.c:1331: Test failed: got 1, expected 0 === w2008s64 (32 bit font) === font.c:1331: Test failed: got 1, expected 0 === w2008s64 (64 bit font) === font.c:1331: Test failed: got 1, expected 0 === w7pro64 (64 bit font) === font.c:1331: Test failed: got 1, expected 0

1 0

Re: [4/4] ws2_32/tests: Add some FIONREAD tests
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3976 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (c0): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 sock.c:3963: Test failed: FIONREAD should have returned 4 bytes, got 0 instead sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock.c:3963: Test failed: FIONREAD should have returned 4 bytes, got 0 instead

1 0

Re: [3/4] ws2_32/tests: Add some WSALookupService[Begin|Next|End] tests
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3975 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 000007FEFE4C9CD9

1 0

Re: kernel32/tests: Add test for FindFirstFileA() (try 3)
by Dmitry Timoshkov Jan. 4, 2014

Jan. 4, 2014

Zhenbo Li <litimetal(a)gmail.com> wrote: > + > + err = GetLastError(); > + ok ( handle != INVALID_HANDLE_VALUE, "FindFirstFile on %s failed\n", buffer2 ); > + ok ( !err , "FindFirstFile failed, Error number %d\n", err ); > + This block looks like an orphaned part of some removed test. -- Dmitry.

2 2

Question about test_RemoveDirectory()
by Zhenbo Li Jan. 4, 2014

Jan. 4, 2014

Hello, I found that test_RemoveDirectory() is in dlls/kernel32/tests/file.c, while RemoveDirectoryA() and RemoveDirectoryW() are in dlls/kernel32/path.c I checked git log, and found that they came from commit ad9b79932410f7c, Reimplemented CreateDirectoryW and RemoveDirectoryW using ntdll functions. Should I move test_RemoveDirectory() to dlls/kernel32/tests/path.c? Thanks. -- Have a nice day! Zhenbo Li

1 0

Re: kernel32/tests: Add test for FindFirstFileA() (try 2)
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3973 Your paranoid android. === wxppro (32 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0 === wvista (32 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0 === w2008s64 (32 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0 === w7pro64 (32 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0 === w2008s64 (64 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0 === w7pro64 (64 bit file) === file.c:2452: Test failed: FindFirstFile failed, Error number 0

1 0

Re: ntdll/tests: Add test for deleting via NtOpenFile
by Marvin Jan. 4, 2014

Jan. 4, 2014

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=3962 Your paranoid android. === w7pro64 (32 bit file) === file.c:331: Test failed: open L"system32" failed c000003b file.c:338: Test failed: open L"SYSTEM32" failed c000003b file.c:346: Test failed: open L"\\SYSTEM32" failed c0000034 file.c:356: Test failed: open L"\\SYSTEM32" failed c000003b

2 1

Re: [PATCH 5/5] d3dx9_36/tests: Use NAN.
by Francois Gouget Jan. 3, 2014

Jan. 3, 2014

On Thu, 2 Jan 2014, Stefan Dösinger wrote: [...] > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -4800,7 +4800,7 @@ static void test_create_skin_info(void) [...] > - exp_weights[1] = 0.0f / 0.0f; /* NAN */ > + exp_weights[1] = NAN; This patch breaks the compilation on Solaris because it does not define NAN (except in math_c99.h but we cannot use that, see below). But independently from that I think it's wrong because one should be able to compile the conformance tests on Windows. This means we cannot use things like config.h or port.h and should only use stuff that's defined in Windows headers. But as far as I can tell the Windows SDK does not define NAN. There is a definition of NAN in the CRT xmath.h header but Wine does not have that header and we're obviously not including it here. So one solution would be to revert the patch. Another would be to copy wine/port.h's __port_nan() definition. Yet another might be to add xmath.h and a dependency on msvcrt.dll. But maybe there's a better way still? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

2 2

Re: strmbase: Store BasePinFuncTable inside Base*PinFuncTable structs.
by Alexandre Julliard Jan. 3, 2014

Jan. 3, 2014

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/amstream/mediastreamfilter.c | 15 +++++++-------- > dlls/qcap/avico.c | 32 ++++++++++++++------------------ > dlls/qcap/avimux.c | 32 ++++++++++++++------------------ > dlls/qcap/vfwcapture.c | 15 +++++++-------- > dlls/quartz/filesource.c | 15 +++++++-------- > dlls/quartz/parser.c | 15 +++++++-------- > dlls/strmbase/pin.c | 24 ++++++++++++------------ > dlls/strmbase/renderer.c | 17 ++++++++--------- > dlls/strmbase/transform.c | 30 ++++++++++++++---------------- > include/wine/strmbase.h | 7 +++++-- > 10 files changed, 95 insertions(+), 107 deletions(-) There are other users, like winegstreamer and wineqtdecoder. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: Add test for FindFirstFileA()
by Marvin Jan. 3, 2014

Jan. 3, 2014

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=3963 Your paranoid android. === wxppro (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooD.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === wvista (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooFB6A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo9FA.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo580A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo93F.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooF4B6.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267

1 0

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection (try2)
by Dmitry Timoshkov Jan. 3, 2014

Jan. 3, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref-1; > +} This one still looks somewhat strange. Why not do something more straightforward like the following one? static inline ULONG get_refcount(IUnknown *iface) { IUnknown_AddRef(iface); return IUnknown_Release(iface); } -- Dmitry.

1 0

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection
by Dmitry Timoshkov Jan. 3, 2014

Jan. 3, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref; > +} This implementation may lead to wrong conclusions. -- Dmitry.

2 3

How to bisect the 1.6.x series of commits
by Alan W. Irwin Jan. 3, 2014

Jan. 3, 2014

I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date. The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot builds and tests, but when I recently tried 1.6.1, my usual parallel tests of PLplot software failed with an error indicating plot devices (small dll's) cannot be dynamically loaded by the PLplot principal library for that version of Wine. (The problem disappears if I do the tests sequentially for 1.6.1, but I obviously want to avoid that method of testing because it doubles the test time for my two-cpu PC.) The tests of 1.6-rc4 and 1.6.1 were quite similar but not absolutely identical so I do have to confirm the regression in behaviour for 1.6.1 with absolutely identical tests. But assuming I can do that, then I still have to discover if the problem occurred for 1.6. If so, the bisection needs to be an ordinary principal branch one that I am already familiar with between 1.6-rc4 and 1.6, but if not it needs to follow the 1.6.x development branch between 1.6 an 1.6.1. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

4 4

Re: advapi32/tests: Use BOOL type where appropriate
by Dmitry Timoshkov Jan. 3, 2014

Jan. 3, 2014

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > diff --git a/dlls/advapi32/tests/security.c b/dlls/advapi32/tests/security.c > index 9f1e611..232a729 100644 > --- a/dlls/advapi32/tests/security.c > +++ b/dlls/advapi32/tests/security.c > @@ -4526,13 +4526,14 @@ static void test_mutex_security(HANDLE token) > STANDARD_RIGHTS_ALL | MUTEX_ALL_ACCESS }; > static const struct > { > - int todo, generic, mapped; > + BOOL todo; > + int generic, mapped; > } map[] = > { > - { 1, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > - { 0, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > - { 0, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > - { 0, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > + { TRUE, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > + { FALSE, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > + { FALSE, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > + { FALSE, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > }; Please don't touch these tests, 'int' is intentionally used here, and 'BOOL' buys you nothing. It's better to actually fix the source of these todos and remove them altogether. -- Dmitry.

1 0

Re: ddraw/tests: Use BOOL type where appropriate
by Marvin Jan. 3, 2014

Jan. 3, 2014

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=3950 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

1 0

Re: [PATCH] ntdll: Improve handling of THUMB_MOV32 relocations
by André Hentschel Jan. 2, 2014

Jan. 2, 2014

Am 02.01.2014 17:01, schrieb Martin Storsjo: > Since the delta variable actually is signed, the delta > 0xffff > condition could be false even if the high part of the delta > was nonzero, ending up with not updating the high half of the > relocation at all. > > Additionally, carry any overflow from the low word into the > high word delta. Hi, Do you have an App that triggers that? So you mean the case when the sign bit is used, e.g. 10101010b... Then the delta is negative, but is everything set correctly in the instruction? > --- > dlls/ntdll/loader.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index e0907e7..1f13424 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2230,19 +2230,19 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count > DWORD inst = *(INT_PTR *)((char *)page + offset); > DWORD imm16 = ((inst << 1) & 0x0800) + ((inst << 12) & 0xf000) + > ((inst >> 20) & 0x0700) + ((inst >> 16) & 0x00ff); > + int hi_delta; Why you're using int here? DWORD looks much better for this.

2 2

Re: msvcp80: Fix ostreambuf_iterator<char> structure definition
by Alexandre Julliard Jan. 2, 2014

Jan. 2, 2014

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcp90/ios.c | 88 > +++++++++++++++++++++++++++++++++++++------------- > dlls/msvcp90/msvcp90.h | 6 ++++ > 2 files changed, 72 insertions(+), 22 deletions(-) It breaks the Mingw build: locale.o:locale.c:(.text+0x94c): undefined reference to `_num_put_char_do_put_long(a)28' locale.o:locale.c:(.text+0x954): undefined reference to `_num_put_char_put_long(a)28' locale.o:locale.c:(.text+0x95c): undefined reference to `_num_put_char_do_put_ulong(a)28' locale.o:locale.c:(.text+0x964): undefined reference to `_num_put_char_put_ulong(a)28' locale.o:locale.c:(.text+0x96c): undefined reference to `_num_put_char_do_put_double(a)32' locale.o:locale.c:(.text+0x974): undefined reference to `_num_put_char_put_double(a)32' locale.o:locale.c:(.text+0x97c): undefined reference to `_num_put_char_put_ldouble(a)32' locale.o:locale.c:(.text+0x984): undefined reference to `_num_put_char_do_put_ptr(a)28' locale.o:locale.c:(.text+0x98c): undefined reference to `_num_put_char_put_ptr(a)28' locale.o:locale.c:(.text+0x994): undefined reference to `_num_put_char_do_put_int64(a)32' locale.o:locale.c:(.text+0x99c): undefined reference to `_num_put_char_put_int64(a)32' locale.o:locale.c:(.text+0x9a4): undefined reference to `_num_put_char_do_put_uint64(a)32' locale.o:locale.c:(.text+0x9ac): undefined reference to `_num_put_char_put_uint64(a)32' locale.o:locale.c:(.text+0x9b4): undefined reference to `_num_put_char_do_put_bool(a)28' locale.o:locale.c:(.text+0x9bc): undefined reference to `_num_put_char_put_bool(a)28' locale.o:locale.c:(.text+0xa0c): undefined reference to `_num_put_wchar_do_put_long(a)28' locale.o:locale.c:(.text+0xa14): undefined reference to `_num_put_short_do_put_long(a)28' locale.o:locale.c:(.text+0xa1c): undefined reference to `_num_put_wchar_put_long(a)28' locale.o:locale.c:(.text+0xa24): undefined reference to `_num_put_wchar_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa2c): undefined reference to `_num_put_short_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa34): undefined reference to `_num_put_wchar_put_ulong(a)28' locale.o:locale.c:(.text+0xa3c): undefined reference to `_num_put_wchar_do_put_double(a)32' locale.o:locale.c:(.text+0xa44): undefined reference to `_num_put_short_do_put_double(a)32' locale.o:locale.c:(.text+0xa4c): undefined reference to `_num_put_wchar_put_double(a)32' locale.o:locale.c:(.text+0xa54): undefined reference to `_num_put_wchar_put_ldouble(a)32' locale.o:locale.c:(.text+0xa5c): undefined reference to `_num_put_wchar_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa64): undefined reference to `_num_put_short_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa6c): undefined reference to `_num_put_wchar_put_ptr(a)28' locale.o:locale.c:(.text+0xa74): undefined reference to `_num_put_wchar_do_put_int64(a)32' locale.o:locale.c:(.text+0xa7c): undefined reference to `_num_put_short_do_put_int64(a)32' locale.o:locale.c:(.text+0xa84): undefined reference to `_num_put_wchar_put_int64(a)32' locale.o:locale.c:(.text+0xa8c): undefined reference to `_num_put_wchar_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa94): undefined reference to `_num_put_short_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa9c): undefined reference to `_num_put_wchar_put_uint64(a)32' locale.o:locale.c:(.text+0xaa4): undefined reference to `_num_put_wchar_do_put_bool(a)28' locale.o:locale.c:(.text+0xaac): undefined reference to `_num_put_short_do_put_bool(a)28' locale.o:locale.c:(.text+0xab4): undefined reference to `_num_put_wchar_put_bool(a)28' locale.o:locale.c:(.text+0xaec): undefined reference to `_time_put_char_do_put(a)36' locale.o:locale.c:(.text+0xaf4): undefined reference to `_time_put_char_put(a)36' locale.o:locale.c:(.text+0xafc): undefined reference to `_time_put_char_put_format(a)36' locale.o:locale.c:(.text+0xb5c): undefined reference to `_time_put_wchar_do_put(a)36' locale.o:locale.c:(.text+0xb64): undefined reference to `_time_put_wchar_put(a)36' locale.o:locale.c:(.text+0xb6c): undefined reference to `_time_put_wchar_put_format(a)36' collect2: ld returned 1 exit status -- Alexandre Julliard julliard(a)winehq.org

1 0

testbot problem
by Stefan Leichter Jan. 2, 2014

Jan. 2, 2014

Hello, i'm trying to understand why job 27632 did not build on the testbot. It builds fine for Linux 32/64 bit and Windows (make crosstest) on my computer. >From the build log it looks like a problem inside the Makefile (make: Nothing to be done for `all'.). Is there a way to access the Makefile after the job is finished? Regards Stefan

1 0

Better managing icons files names
by Pedro Henrique Lara Campos Jan. 2, 2014

Jan. 2, 2014

Can Wine or could it in newer versions, use a prefix for their icons, like wine_56BA_Tcharam.png, or maybe their own folder? My ~/.local/share/icons is like... full of bottles, every corner I look, I find an icon from wine :P

3 2

Re: [PATCH] msxml3: avoid double free of str (Coverity)
by Marvin Jan. 1, 2014

Jan. 1, 2014

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=3919 Your paranoid android. === wxppro (32 bit domdoc) === domdoc.c:9860: Test failed: got 00244F94

1 0

Re: [PATCH 12/21] kernel32: conditional variable support (try 6)
by Marcus Meissner Jan. 1, 2014

Jan. 1, 2014

Hmm, THis should have been patch 0021 instead of 0012 , please disregard. Ciao, Marcus On Wed, Jan 01, 2014 at 07:44:16PM +0100, Marcus Meissner wrote: > Hi, > > Additional tightening and cleaning of comments. > > After Alexandres last guidance ("no global allocation") > and some hours of hair pulling I now did a implementation > with just a linked list of waiters. > > variable->Ptr points to the head of this list. > > The bit 0 of variable->Ptr is used for atomic locking of > the list and also its content, avoiding need for a lock variable. > > Small issues: > We are busy waiting on the bit 0 lock, not the most performance > wise best thing. > > Ciao, Marcus > --- > dlls/kernel32/kernel32.spec | 4 ++ > dlls/kernel32/sync.c | 151 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 155 insertions(+) > > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index 7779a75..e8d2bf0 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -750,6 +750,7 @@ > @ stdcall InitOnceComplete(ptr long ptr) > @ stdcall InitOnceExecuteOnce(ptr ptr ptr ptr) > @ stdcall InitOnceInitialize(ptr) ntdll.RtlRunOnceInitialize > +@ stdcall InitializeConditionVariable(ptr) > @ stdcall InitializeCriticalSection(ptr) > @ stdcall InitializeCriticalSectionAndSpinCount(ptr long) > @ stdcall InitializeCriticalSectionEx(ptr long long) > @@ -1194,6 +1195,7 @@ > @ stdcall SignalObjectAndWait(long long long long) > @ stdcall SizeofResource(long long) > @ stdcall Sleep(long) > +@ stdcall SleepConditionVariableCS(ptr ptr long) > @ stdcall SleepEx(long long) > @ stdcall SuspendThread(long) > @ stdcall SwitchToFiber(ptr) > @@ -1263,6 +1265,8 @@ > @ stdcall WaitForSingleObjectEx(long long long) > @ stdcall WaitNamedPipeA (str long) > @ stdcall WaitNamedPipeW (wstr long) > +@ stdcall WakeAllConditionVariable (ptr) > +@ stdcall WakeConditionVariable (ptr) > @ stdcall WerRegisterFile(wstr long long) > @ stdcall WerRegisterMemoryBlock(ptr long) > @ stdcall WerRegisterRuntimeExceptionModule(wstr ptr) > diff --git a/dlls/kernel32/sync.c b/dlls/kernel32/sync.c > index 3c9e42a..34f39cd 100644 > --- a/dlls/kernel32/sync.c > +++ b/dlls/kernel32/sync.c > @@ -2327,3 +2327,154 @@ __ASM_STDCALL_FUNC(InterlockedDecrement, 4, > "ret $4") > > #endif /* __i386__ */ > + > +/* See http://locklessinc.com/articles/mutex_cv_futex/ for a futex implementation > + * See http://www.cs.wustl.edu/~schmidt/win32-cv-1.html for various implementations > + * of pthread_cond_* with Win32 primitives. > + * See glibc/nptl/DESIGN-condvar.txt for the glibc implementation > + * > + * This implementation uses a linked list as waiter queue, and the list > + * and its content is locked for access via bit 0 of variable->Ptr. > + * The actual waiting is done using a Win32 Event. > + */ > + > +struct _condvar_intern { > + struct _condvar_intern *next; > + HANDLE event; > +}; > + > +/********************************************************************** > + * InitializeConditionVariable (KERNEL32.@) > + */ > +VOID WINAPI InitializeConditionVariable(PCONDITION_VARIABLE variable) > +{ > + variable->Ptr = NULL; > +} > + > +/* > + * We lock the condition variable by setting bit 0 in variable->Ptr > + * atomically. We busy loop until we succeed and return the current value. > + * We also lock the empty list (NULL). > + * > + * List unlocking is done with "variable->Ptr = <retvalue>" > + */ > +static struct _condvar_intern* > +_lock_list (PCONDITION_VARIABLE variable) { > + struct _condvar_intern *oldvar, *var; > + > + do { > + __asm__ __volatile__("":::"memory"); > + var = variable->Ptr; > + if ((DWORD_PTR)var & 1) continue; /* locked already, retry. */ > + > + oldvar = InterlockedCompareExchangePointer (&variable->Ptr, (void*)((DWORD_PTR)var|1), var); > + if (oldvar == var) > + break; > + /* failed atomic locking, retry. */ > + } while (1); > + return var; > +} > + > +/********************************************************************** > + * WakeConditionVariable (KERNEL32.@) > + */ > +VOID WINAPI WakeConditionVariable(PCONDITION_VARIABLE variable) > +{ > + struct _condvar_intern *var; > + > + if (!variable->Ptr) > + return; > + > + var = _lock_list (variable); > + if (!var) { > + variable->Ptr = NULL; > + return; > + } > + > + /* remove and wake up the first entry */ > + NtSetEvent (var->event, NULL); > + > + variable->Ptr = var->next; > +} > + > +/********************************************************************** > + * WakeAllConditionVariable (KERNEL32.@) > + */ > +VOID WINAPI WakeAllConditionVariable(PCONDITION_VARIABLE variable) > +{ > + struct _condvar_intern *var; > + > + if (!variable->Ptr) > + return; > + > + var = _lock_list (variable); > + > + /* dequeue the whole waiter chain and wake it up */ > + while (var) { > + NtSetEvent (var->event, NULL); > + var = var->next; > + } > + > + variable->Ptr = NULL; > +} > + > +/********************************************************************** > + * SleepConditionVariableCS (KERNEL32.@) > + */ > +BOOL WINAPI SleepConditionVariableCS(PCONDITION_VARIABLE variable, > + LPCRITICAL_SECTION crit, DWORD timeout > +) > +{ > + struct _condvar_intern myself; > + struct _condvar_intern **xvar, *var; > + BOOL ret = TRUE; > + OBJECT_ATTRIBUTES attr; > + DWORD res; > + > + attr.Length = sizeof(attr); > + attr.RootDirectory = 0; > + attr.Attributes = OBJ_INHERIT; > + attr.ObjectName = NULL; > + attr.SecurityDescriptor = NULL; > + attr.SecurityQualityOfService = NULL; > + > + NtCreateEvent (&myself.event, EVENT_ALL_ACCESS, &attr, NotificationEvent, 0); > + myself.next = NULL; > + > + var = _lock_list (variable); > + /* Attach our stack based struct to the end of the list. > + * (at the end for fairness) > + */ > + xvar = &var; > + while (*xvar) > + xvar = &(*xvar)->next; > + *xvar = &myself; > + variable->Ptr = var; > + > + RtlLeaveCriticalSection(crit); > + > + res = WaitForSingleObject(myself.event, timeout); > + > + var = _lock_list (variable); > + > + /* Remove our entry */ > + xvar = (struct _condvar_intern **)&var; > + while (*xvar) { > + if (*xvar == &myself) { > + *xvar = (*xvar)->next; > + break; > + } > + xvar = &(*xvar)->next; > + } > + variable->Ptr = var; > + > + CloseHandle (myself.event); > + RtlEnterCriticalSection(crit); > + > + if (res == WAIT_TIMEOUT) { > + ret = FALSE; > + /* expected from caller, but not set by WaitForSingleObject */ > + SetLastError(ERROR_TIMEOUT); > + } > + return ret; > +} > -- > 1.7.10.4 > > > >

1 0

Re: [PATCH] msxml3: avoid double free of str (Coverity)
by Nikolay Sivov Jan. 1, 2014

Jan. 1, 2014

On 1/1/2014 22:15, Marcus Meissner wrote: > 1127305 Double free > --- > dlls/msxml3/tests/domdoc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > index df11197..f653a8b 100644 > --- a/dlls/msxml3/tests/domdoc.c > +++ b/dlls/msxml3/tests/domdoc.c > @@ -11047,7 +11047,6 @@ static void test_xmlns_attribute(void) > ok( hr == S_OK, "got 0x%08x\n", hr); > todo_wine ok( lstrcmpW(str, _bstr_("<Testing xmlns:dt=\"urn:schemas-microsoft-com:datatypes\" dt:dt=\"bin.base64\"/>")) == 0, > "got %s\n", wine_dbgstr_w(str)); > - SysFreeString(str); This is a correct fix technically, but it's better to remove second SysFreeString(), not this one. Speaking of style, I'd probably remove all 'if (hr == S_OK)' check, it never fails, or reduced a scope of 'str'.

1 0

Re: [PATCH] msxml3: avoid double free of str (Coverity)
by Marvin Jan. 1, 2014

Jan. 1, 2014

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=3918 Your paranoid android. === wxppro (32 bit domdoc) === domdoc.c:9860: Test failed: got 00244F94

1 0

about eventlog
by Akira Nakagawa Jan. 1, 2014

Jan. 1, 2014

I examined the design of RegistereventSource(). The return value type is HANDLE,but the details of it is unknown. However,I suppose,the code should be like this(I'm not good at coding of Win32) /****************************************************************************** * RegisterEventSourceW [ADVAPI32.@] * * See RegisterEventSourceA. */ HANDLE WINAPI RegisterEventSourceW( LPCWSTR lpUNCServerName, LPCWSTR lpSourceName ) { int arg_length,path_length; LPDWORD existance; LPWSTR reg_fullpath; LPWSTR filename; LPDWORD lptype; LPWSTR lpdata,gldata; HKEY hkeyp; HANDLE eventhandle; int number_of_entry,length_of_dat; FIXME("(%s,%s): stub\n", debugstr_w(lpUNCServerName), debugstr_w(lpSourceName)); if(lpUNCServerName!=NULL) { FIXME("lpUNCServerName:%s\nExecution in another server is not suppported.", debugstr_w(lpUNCServerName)); } else { existance = NULL; number_of_entry = 0; length_of_dat = 0; filename = (LPWSTR)"Application";//FIXME:this should be all of sub keies. reg_fullpath = lstrcatW((LPWSTR)"System\\CurrentControlSet\\Sevices\\Eventlog\\Application\\",lpSourceName); arg_length = lstrlenW(lpSourceName); RegCreateKeyExW(HKEY_LOCAL_MACHINE,reg_fullpath,0, NULL,REG_OPTION_NON_VOLATILE,KEY_READ,NULL,&hkeyp,existance);//Create or open key. RegQueryInfoKeyW(hkeyp,NULL,0,NULL,NULL,NULL,NULL, (LPDWORD)number_of_entry,NULL,(LPDWORD)length_of_dat,NULL,NULL); if(length_of_dat<2 || number_of_entry<2)//Key entry is void. return NULL; *lptype=(REG_SZ); RegQueryValueExW(hkeyp,(LPWSTR)"EventMessageFile",NULL,lptype,(LPBYTE)lpdata,(LPDWORD)path_length); RegCloseKey(hkeyp); eventhandle = GlobalAlloc(GHND,(arg_length+path_length)*sizeof(LPWSTR)); gldata=(LPWSTR)GlobalLock(eventhandle); //After that,store data follows:filename,file path,source name;I do not know how to. if(eventhandle==INVALID_HANDLE_VALUE) { ERR_(eventlog)("%s\n", debugstr_w(lpUNCServerName)); return NULL; } } return eventhandle; }

1 0

Re: [PATCH 3/3] ws2_32: Add an interactive test for interface change notifications (rebased).
by Marvin Jan. 1, 2014

Jan. 1, 2014

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=3915 Your paranoid android. === wxppro (32 bit sock) === sock.c:554: Test failed: oob_server (5a8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB4047 === w2008s64 (32 bit sock) === sock.c:554: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:554: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 000007FEFE4C9CD9

1 0