February 2013 - Wine-devel - list.winehq.org

64bit integer overflow in 3 days
by Joerg-Cyril.Hoehle＠t-systems.com 15 Feb '13

15 Feb '13

Hi, You believe that 64bit integers give you plenty of room and time to avoid trouble like Y2k and Y2033, don't you? The trouble is, these large data types make using other large numbers more attractive than they used to be, e.g. counting time in 100 nanosecond units, representing one second as 10000000. Combining large numbers will cause an overflow sooner than you think. Specifically, the pattern X * numerator / denominator is troublesome. Let's analyse winealsa:AudioClock_GetPosition: QueryPerformanceCounter(&stamp); QueryPerformanceFrequency(&frequency); *qpctime = (stamp.QuadPart * (INT64)10000000) / frequency.QuadPart; QueryPerformanceCounter (QPC) returns time in an unspecified unit (frequency) and needs to convert that into 100 nanosecond units. Graphically, with g - garbage bits, s - shifted, X - valid bits: 6 5 4 3 2 1 4321098765432109876543210987654321098765432109876543210987654321 <<< shift left, multiply divide, shift right >>> Assuming QPC returns 64 valid bits: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX QPC Multiply with (INT64)10000000 (log2 ~ 23): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsssssssssssssssssssssss *10000000 Divide by frequency (happens to be 10000000 too): gggggggggggggggggggggggXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /10000000 (100ns) You start to see how the number of valid bits already shrunk a lot. Now you don't care about nanoseconds, you want seconds. Divide again: ggggggggggggggggggggggggggggggggggggggggggggggXXXXXXXXXXXXXXXXXX /10000000 (seconds) Ouch, only 18bits left to express seconds! How many days is that? (/ (ash 1 18) 3600.0 24) -> ~3.03 So after 3 days in Wine, mmdevapi's GetPosition clock has wrapped. 3 days is not much compared to over 50000 years that 64 bit integers allow to express with 100 nanosecond units, isn't it? I don't know if GetPosition is related to bug #26968 where a user reports that foobar stops playing audio after 4-7 days, but you get a clue. Cross-check: 0x40000 is 1^18 seconds ~ 3 days 0x2625A000000 same in 100 nanosecond units 0x16BCC41E900000000 the * (INT64)10000000 part in winealsa ^1 bit unsigned overflow (more with signed integers) 0x6BCC41E900000000 clipped 0xB4DAD65435 after /10000000, a value already reached after ~21 hours There are even less bits, because LARGE_INTEGER is signed. There are several instances of that X * p / q pattern in Wine. Examples: ntdll/threadpool.c:queue_current_time: return now.QuadPart * 1000 / freq.QuadPart; ntdll/kernel_main.c:GetTickCount64: return counter.QuadPart * 1000 / frequency.QuadPart; IOW, GetTickCount64 does not offer 64 valid bits. ntdll/time.c:monotonic_counter: return mach_absolute_time() * timebase.numer / timebase.denom / 100; This means that on MacOS, QPC may overflow even earlier because it does not offer 64 valid bits. I've prepared a few patches to fix some of these. Generally, I don't know what to recommend. Use double floating point intermediates and loose 11 bits for the exponent but at least get the magnitude right? Regards, Jörg Höhle

2 1

Re: d3dx9: Specify arguments in trace to ease debugging
by Alexandre Julliard 15 Feb '13

15 Feb '13

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > Hello. > > I took advantage of this minor patch to clean up and make uniform the > coding style of this file. Please don't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added support for a few more constants
by Marvin 15 Feb '13

15 Feb '13

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=24408 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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: d3dx9: Specify arguments in trace to ease debugging
by Rico Schüller 15 Feb '13

15 Feb '13

On 15.02.2013 08:20, Nozomi Kodama wrote: > @@ -721,9 +739,10 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation(D3DXMATRIX *pout, const D3DXVECTOR3 > > @@ -797,69 +821,70 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation2D(D3DXMATRIX *pout, const D3DXVECTOR Those two functions need a speed improvement. Normally we change only the code (and it's style) if we touch that area. I'm not a fan of changing that in one go in a huge patch, as it might introduce new mistakes, see below. I'm not sure if I caught all issues. > + rot.w = cos(rotation/2.0f); rot.w = cos(rotation / 2.0f); > > - TRACE("iface %p\n", iface); > + TRACE("iface %p, %pm\n", iface, pm); Typo. > + TRACE("iface %p, x %f, y %f, z %f\n", iface, x, y, z); > > + TRACE("(pout %p, pvpoint %p, pvnormal %p)\n", pout, pvpoint, pvnormal); Well, I would use the same style for both... I'd prefer the first one. Cheers Rico

1 0

Re: [PATCH 2/2] wininet: Set available bytes in InternetQueryDataAvailable even if it ends up in async call
by Marvin 14 Feb '13

14 Feb '13

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=24401 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Where to put Chinese translation of the Wine user guide?
by Jactry Zeng 14 Feb '13

14 Feb '13

Hi folks, A Chinese Wine user Liu Hongcong had translated [1] the Wine user guide [2] to Chinese three years ago, the translation looks mostly good to me. It is a pity to leave his translation outside of the official wine website. With his consent, I want to put his translation to winehq. But I can't find where to add it into in website's source [3]. Or I should add it into wiki? Thanks for any comment! [1] http://blog.csdn.net/hongmy525/article/details/2238600 [2] http://www.winehq.org/docs/wineusr-guide/index [3] http://source.winehq.org/git/website.git/

2 2

Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

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=24396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [2/4] gdi32: OffsetClipRgn should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

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=24395 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [1/4] gdi32: Add more EMF clipping tests.
by Marvin 14 Feb '13

14 Feb '13

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=24394 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH] dsound: copy program parameters in SetFormat
by Andrew Eikum 13 Feb '13

13 Feb '13

On Mon, Feb 11, 2013 at 02:06:42PM +0100, Maarten Lankhorst wrote: > Fixes bug #32312, apparently some programs depend on the format it specifies being returned. > > Just set wBitsPerSample, nSamplesPerSec and nChannels to make those applications happy. > The patch seems fine, but can you add some tests for this so we can nail down exactly what we should be taking from the SetFormat format? E.g. should we just do "device->primary_fmt = CopyFormat(passed_fmt)" in all cases, or can you find a case where the GetFormat() result is changed? FYI, your patch applies with an offset and the Wine patch tracker didn't like this: > --- a/dlls/dsound/primary.c > +++ a/dlls/dsound/primary.c but git-am imported the raw mail file just fine. Andrew

1 0