July 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] shell32: Disable WOW64 redirection when converting pidls to UNIX paths.

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 http://testbot.winehq.org/JobDetails.pl?Key=12975 Your paranoid android. === WNT4WSSP6 (32 bit shlfolder) === Timeout === W2KPROSP4 (32 bit shlfolder) === Timeout

July 28, 2011

Re: patch for dlls/gdi32/dib.c: fixes crash

by Huw Davies

On Thu, Jul 28, 2011 at 04:14:56PM +0200, Wolfgang Walter wrote: > I think that > > bitmapinfo_from_user_bitmapinfo() > > is the real culprit. I think colors gets to big (> 256) and therefore the size > for the memcpy. Hopefully http://source.winehq.org/patches/data/77076 should fix this. Huw.

July 28, 2011

Re: patch for dlls/gdi32/dib.c: fixes crash

by Wolfgang Walter

Am Mittwoch, 27. Juli 2011 schrieben Sie: > On Wed, Jul 27, 2011 at 6:44 PM, Wolfgang Walter <wine(a)stwm.de> wrote: > > - char src_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > > - BITMAPINFO *src_info = (BITMAPINFO *)src_bmibuf; > > - char dst_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > > - BITMAPINFO *dst_info = (BITMAPINFO *)dst_bmibuf; > > There's another instance of that in GetDIBits. Allocating 2KB+ (2 x > 1064 bytes) of data on the stack is not very reasonable I guess. > Hmm, allocating the structure on the stack is not really the problem. The problem is that part if the stack gets overwritten. Allocating the these structures on the heap hides the bug mostly. I think that bitmapinfo_from_user_bitmapinfo() is the real culprit. I think colors gets to big (> 256) and therefore the size for the memcpy. I just insert an test in bitmapinfo_from_user_bitmapinfo() if colors is larger then 256 and this is indeed the case. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

July 28, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 26.07.2011 um 11:29 schrieb Michael Mc Donnell: >> Duplicating the code for 16 and 32 bit indices looks a bit ugly. Maybe you can use inline functions to read and write values from the proper buffer? The other possibility, which the ddraw blitting code uses is to write a sort of template as a macro and then generate both versions, but I don't like that idea. > > Yes I agree it's ugly. I've added the functions read_ib and write_ib > to handle 32 bit indices. Does that look like a good solution to you > too? Looks OK to me. >> Wrt the D3DDECLTYPE epsilon, it may be more efficient to scale the epsilon and calculate the diff and comparison as UBYTEs rather than floats. You'll need the diff functions for the other types like *BYTE*, *SHORT* anyway. Also tests would be helpful here, especially how the epsilon is treated in normalized values like D3DCOLOR and UBYTE4N and how it is treated in non-normalized values like UBYTE4. > > Ok I'll look into that and get back to you later. > >> Wrt the usage/index fields, what happens when a combination that isn't supported by the fixed function pipeline is used, e.g. NORMAL3 or POSITION5? Those are valid in a vertex declaration and can be used with shaders. > > It works because the code does not check the UsageIndex field, except > for differentiating between DIFFUSE and SPECULAR. I've added test 13 > that shows this (tested on Windows 7 and Linux). You may still get into trouble with something like TEXCOORD10 I'd recommend to change test 13(or add a new one) that tests a TEXCOORD > 7 and COLOR > 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOMWvFAAoJEN0/YqbEcdMwwxgP/2oGMavFpdFWaa1GSUY6sVds mkgW5c2vKsb6p5LDFegrkSbwj9m01Wlw9LNqy7nQAExSrm3eW8ZBdyg0z57dWch3 7XBtLZr7cE8VZ2KkS4U5pQd6ixxrj6+McJJuzxE2YBBof4eugUNVN/GA9PV4wG8e LISF6sTmvPxUlauSyxdQGstO7Hv+jx9vvq29du5Gs6CCRwhU16Ho6W/+2vtba+do aSVLqqMfc4w9elgigJSx7RjdjiZvNTtXYYOLA/XKGxsTk0RIDLamyUaAjKWYs0aq a8KvhJnVcpTuE8ZS0F9IuDQWQFrXBIDXGKD69m0KwBYWqmQt3gAH3N6NEuQHkyJF AzYBSA+7MxPmKMhCTzaJyE63YfzdbxaEM0CoCFPoCEk8atysUqhJDMar0o2Bj1dX 1wAEq7biDc8FVyWK8RkeAirFz8emhhTUjtJspSZoqtS9dXIdlTB3hUdTSvgcZOLs HsHqhkKUxKx7RUWqZN/1RtoSbqUWofUIMHM34R8dpJ/+sDkNQ53KRJW8lW3/WepM aL3pph+1uHCP47E7UiEi1+zqLnJRkIIyHCQllyUjM2m6E3TayfijzjJKIPUBAwAu YH2DKp883217SouA4pXhe5KAdQZWoNb/AFvVsK84grAzYKPCSy1BPKMFG0PE88Gr ZouqTTGYGAqdEyN2vel9 =cmM9 -----END PGP SIGNATURE-----

July 28, 2011

Re: ieframe: Moved ie.c tests to ieframe

by Jacek Caban

On 07/28/11 13:45, Marvin wrote: > 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 > http://testbot.winehq.org/JobDetails.pl?Key=12968 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit ie) === > ie.c:62: Test failed: Could not create InternetExplorer instance: 80040154 > ie: unhandled exception c0000005 at 004012F2 The test won't be ran by winetest on this machine, because it's missing the corresponding DLL. Jacek

July 28, 2011

Re: ieframe: Moved ie.c tests to ieframe

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 http://testbot.winehq.org/JobDetails.pl?Key=12968 Your paranoid android. === WNT4WSSP6 (32 bit ie) === ie.c:62: Test failed: Could not create InternetExplorer instance: 80040154 ie: unhandled exception c0000005 at 004012F2

July 28, 2011

Re: ieframe: Moved ie.c tests to ieframe

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 http://testbot.winehq.org/JobDetails.pl?Key=12967 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

July 28, 2011

Re: Bug status transitions ~ bug 27908

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > In the case of bug 27908, there was no release yet, and I don't think > it's unreasonable for a user to report bugs that are in the latest > release. Building from git is a time/space consuming pain for most > users. If a user reports a bug in a very old release, it's not > unreasonable to ask them to try in a newer release before looking at > the bug. If the bug was reported in old wine and fixed in newer, well, > it technically was fixed, but marking it invalid helps prevent skewing > our bug statistics (and may encourage the user to try latest > development releases before reporting bugs) :). I don't see why it would skew the statistics. If the user encountered a bug and we fixed it, it should count as a fix, no matter when the bug is reported. Of course if it's already fixed, it's probably because there was an older report about it, in which case the new one should be marked duplicate. But if it's really a bug we didn't know about that happened to be fixed by "collateral damage", it's still a valid report and should be marked fixed. -- Alexandre Julliard julliard(a)winehq.org

July 28, 2011

Re: Updated Clang static analysis results / Valgrind update

by Austin English

2011/7/26 André Hentschel <nerv(a)dawncrow.de>: > Am 26.07.2011 01:17, schrieb Austin English: >> On Sat, Jul 2, 2011 at 19:15, Austin English <austinenglish(a)gmail.com> wrote: >>> Web space usage was getting a bit high, so I've uploaded a tarball to >>> a file download service: >>> http://www.sendspace.com/file/5hot36 >>> >>> austin(a)aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 >>> ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 >>> >>> to use, just extract and open in your favorite browser: >>> $ firefox index.html >>> >>> this was run against Clang from svn: clang version 3.0 (trunk 134320) >>> >>> Please send me any false positives that you'd like me to report upstream. >>> >>> Cheers, >>> Austin >>> >>> P.S. For those of you wanting Valgrind results, I'm currently hitting >>> a nasty Valgrind bug, waiting on upstream to fix: >>> https://bugs.kde.org/show_bug.cgi?id=275673 >>> >>> (Thanks to Andrew N for finding the faulty commit) >> >> Updated clang results, with: >> clang version 3.0 (trunk 135936) and wine-1.3.25-52-g9d7d37f >> >> are at http://www.sendspace.com/file/x81pne >> 77f1b2d0fdd8cb79d4caf20279b36dc047fcc325 scan-build-2011-07-25.tar.xz >> >> This gives 1815 warnings (previously had 1857). Again, if you see any >> false positives, please let me know so that I can report them >> upstream. >> >> For valgrind, see http://austinenglish.com/logs/valgrind/2011-07-25-10.19 >> I've disabled a few tests, to workaround valgrind bug 275673. See >> http://code.google.com/p/winezeug/source/diff?spec=svn2431&r=2431&format=si… >> >> I've got some more interesting stuff in the works, time permitting. >> Keep tuned ;-). >> >> Cheers, >> Austin >> >> > > in your actual valgrind logs there is quite much noise about > at ??? (in /usr/lib/i386-linux-gnu/libfontconfig.so.1.4.4) > what's that? Thanks for letting me know. I filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635609 for that. I've added a suppression for it, today's results are fontconfig free: http://austinenglish.com/logs/valgrind/2011-07-27-12.24/ Cheers, Austin

July 28, 2011

Re: [PATCH 7/8] wscript: implemented Host_get_Application (resend)

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 http://testbot.winehq.org/JobDetails.pl?Key=12934 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011