Re: [PATCH] oleaut32: OLEPictureImpl_Load uses Seek(STREAM_SEEK_END) to find the stream length
On Thu, Sep 15, 2011 at 08:28:53AM, Marcus Meissner wrote: > On Thu, Sep 15, 2011 at 02:09:56PM +0200, Bernhard Loos wrote: > > --- > > dlls/oleaut32/olepicture.c | 148 > > +- > > dlls/oleaut32/tests/olepicture.c | 16 ++--- > > 2 files changed, 54 insertions(+), 110 deletions(-) > > Did make check work for you even? Marvin does not like it at least. > > This will break NonStatable streams, also seekability of streams can > not be assumed. > > Ciao, Marcus Windows never calls Stat on the stream, and it bails out, if Seek doesn't work, it certainly never reads until the end of the stream. Thats at least what happens on XP. This only breaks on jpeg images, so I suspect the difference is in the actual image rendering code. Wine always reads the complete image into memory and then creates the image from this memory buffer with IWICStream_InitializeFromMemory for example, while windows probably calls IWICStream_InitializeFromIStream. And this method reads a 4096 bytes chunk at first and depends on Read checking for the end of the stream. Bernhard
Re: Something's rotten in git today...
On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel wrote: > On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos > wrote: It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems? >>> >>> It smells like the rpcrt4 change. > > I thought so, too. > >> I admit I'm a bit at a loss, how this could happen. Could you create a >> +seh,+rpc log? >> And does it go away, if you revert those changes? > > I've reproduced it twice now in an hour on two quad-core machines with > the script > > for try in `seq 1 100` > do > echo try $try > server/wineserver -k || true > rm -rf ~/.wine > cd dlls/advapi32/tests > rm -f *.ok > make test > cd ../../msi/tests > rm -f action.ok > make action.ok > cd ../../.. > done > > so it may take me a while to verify that it goes away after reverting > the rpc change > or to get you a detailed log. > > In one of the failures, I got the service.ok failure from above: > > service.c:152: Test failed: Expected success, got error 1060 > err:rpc:I_RpcGetBuffer no binding > service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123 > > In the other, I got a crash in service.ok: > ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p > advapi32_test.exe.so service.c && touch service.ok > err:rpc:I_RpcGetBuffer no binding > err:rpc:I_RpcGetBuffer no binding > wine: Unhandled page fault on read access to 0x60481043 at address > 0x7bc34227 (thread 0021), starting debugger.. > err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed > out in thread 002a, blocked by 0021, retrying (60 sec) > ... This crash is the most interesting thing by far. It looks like it's somewhere in ntdll. Could you please check where exectly? Ntdll should always get mapped to the same place, so if you didn't make any changes to it in the meantime, you can check it with some random wine process without waiting for the crash to happen again > I don't get backtraces much anymore because of that darn deadlock (unrelated > to the current problem), and btall doesn't seem to show a crash (though it > does have some interesting stack traces); see the attachment. > > Austin may have a related crash in rpcrt4_test.exe.so server.c, see > http://bugs.winehq.org/show_bug.cgi?id=28383#c2 >
Re: Something's rotten in git today...
On Thu, Sep 15, 2011 at 7:27 PM, Alexandre Julliard wrote: > Dan Kegel writes: > >> It might be just me, but I've seen five very strange test failures >> today out of about 30 build/test runs. >> Has anybody else noticed problems? > > It smells like the rpcrt4 change. > > -- > Alexandre Julliard > julli...@winehq.org I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
Re: [PATCH 2/5] ddraw: Use offscreen backbuffers.
On 16 September 2011 01:03, Stefan Dösinger wrote: > On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote: >> In principle this allows us to use more than one backbuffer in ddraw. It's >> also a requirement for the next patch. > I think this, and the next patch should be implemented in wined3d by handling > D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw > in your patches. > Maybe after 1.4, it's a bit more invasive to do it in wined3d. We don't want render the frontbuffer offscreen unless the swap effect is actually flip for performance reasons. However, the swap effect can potentially change when a reset happens. It's possible to make that all work, but I'd rather wait a bit to see how this works out for ddraw first. > In patch 3 I'm not sure what happens when the app draws to the frontbuffer > directly. Maybe I'm a bit too tired to see it, but doesn't that result in a > blit of the surface onto itself? > No, the wined3d frontbuffer and ddraw frontbuffer are different surfaces.
Re: [PATCH 2/5] ddraw: Use offscreen backbuffers.
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote: > In principle this allows us to use more than one backbuffer in ddraw. It's > also a requirement for the next patch. I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches. d3d8 and d3d9 apps can request multiple backbuffers and access them explicitly just like ddraw apps can. In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself? signature.asc Description: This is a digitally signed message part.
Re: amd processors seem slow at running configure?
On 15. sep. 2011 21:35, Dan Kegel wrote: My new AMD a8-3850 takes 77 seconds to run wine's configure script. (Using -C cuts the time by 40 seconds.) Austin's Phenom II X4 940 takes 61 seconds. My i7 takes 32 seconds... but even the lowly e7300 only takes 38 seconds. The same seems to hold for doing builds with ccache; AMD fares poorly there somehow compared to similar intel chips. Does anyone have an AMD-based system that can run configure in under 40 seconds? My AMD Phenom(tm) II X6 1055T Processor runs it in about 30 seconds.
amd processors seem slow at running configure?
My new AMD a8-3850 takes 77 seconds to run wine's configure script. (Using -C cuts the time by 40 seconds.) Austin's Phenom II X4 940 takes 61 seconds. My i7 takes 32 seconds... but even the lowly e7300 only takes 38 seconds. The same seems to hold for doing builds with ccache; AMD fares poorly there somehow compared to similar intel chips. Does anyone have an AMD-based system that can run configure in under 40 seconds?
Re: [PATCH] rpcrt4/rpc_transport.c: the named pipe can be used for multiple operations at the same time, so use overlapped operations for ReadFile and WriteFile
Le 14/09/2011 14:19, Bernhard Loos a écrit : --- dlls/rpcrt4/rpc_transport.c | 53 +++--- 1 files changed, 29 insertions(+), 24 deletions(-) Hi! I had a quite similar patch, but you beat me! Anyway, aren't those funtions susceptible to be called in a multithreaded environment? If so, having an unique event for all the read or write operations seems dangerous to me. Regards. Jérôme.
Re: Something's rotten in git today...
On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos wrote: >>> It might be just me, but I've seen five very strange test failures >>> today out of about 30 build/test runs. >>> Has anybody else noticed problems? >> >> It smells like the rpcrt4 change. I thought so, too. > I admit I'm a bit at a loss, how this could happen. Could you create a > +seh,+rpc log? > And does it go away, if you revert those changes? I've reproduced it twice now in an hour on two quad-core machines with the script for try in `seq 1 100` do echo try $try server/wineserver -k || true rm -rf ~/.wine cd dlls/advapi32/tests rm -f *.ok make test cd ../../msi/tests rm -f action.ok make action.ok cd ../../.. done so it may take me a while to verify that it goes away after reverting the rpc change or to get you a detailed log. In one of the failures, I got the service.ok failure from above: service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123 In the other, I got a crash in service.ok: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding wine: Unhandled page fault on read access to 0x60481043 at address 0x7bc34227 (thread 0021), starting debugger.. err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed out in thread 002a, blocked by 0021, retrying (60 sec) ... I don't get backtraces much anymore because of that darn deadlock (unrelated to the current problem), and btall doesn't seem to show a crash (though it does have some interesting stack traces); see the attachment. Austin may have a related crash in rpcrt4_test.exe.so server.c, see http://bugs.winehq.org/show_bug.cgi?id=28383#c2 Wine-dbg>0x68000830 GLIBC_2+0x830 in ld-linux.so.2: int $0x80 Backtracing for thread 0015 in process 000c (C:\windows\system32\services.exe): Backtrace: =>0 0x68000830 GLIBC_2+0x830() in ld-linux.so.2 (0x00b3e358) 1 0x7bc83518 NTDLL_wait_for_multiple_objects+0x26c(count=0x1, handles=0xb3e5f8, flags=0x4, timeout=(nil), signal_object=0x0(nil)) [/home/dank/wine-git/dlls/ntdll/sync.c:1124] in ntdll (0x00b3e578) 2 0x7bc8361b NtWaitForMultipleObjects+0x67(count=0x1, handles=0xb3e5f8, wait_all=0, alertable=0, timeout=(nil)) [/home/dank/wine-git/dlls/ntdll/sync.c:1162] in ntdll (0x00b3e5c8) 3 0x7b871de9 WaitForMultipleObjectsEx+0x134(count=0x1, handles=0xb3e750, wait_all=0, timeout=0x, alertable=0) [/home/dank/wine-git/dlls/kernel32/sync.c:188] in kernel32 (0x00b3e718) 4 0x7b871c21 WaitForSingleObject+0x3b(handle=0x4c, timeout=0x) [/home/dank/wine-git/dlls/kernel32/sync.c:128] in kernel32 (0x00b3e748) 5 0x7b83d8c9 GetOverlappedResult+0xc9(hFile=0x48, lpOverlapped=0x1120a0, lpTransferred=0xb3e7c4, bWait=0x1) [/home/dank/wine-git/dlls/kernel32/file.c:602] in kernel32 (0x00b3e798) 6 0x685df561 rpcrt4_conn_np_read+0x98(Connection=0x112028, buffer=0xb3e88c, count=0x10) [/home/dank/wine-git/dlls/rpcrt4/rpc_transport.c:418] in rpcrt4 (0x00b3e7e8) 7 0x685d46a5 rpcrt4_conn_read+0x24(Connection=0x112028, buffer=0xb3e88c, len=0x10) [/home/dank/wine-git/dlls/rpcrt4/rpc_binding.h:177] in rpcrt4 (0x00b3e808) 8 0x685d79e2 RPCRT4_default_receive_fragment+0xbc(Connection=0x112028, Header=0xb3e9c8, Payload=0xb3e908) [/home/dank/wine-git/dlls/rpcrt4/rpc_message.c:1297] in rpcrt4 (0x00b3e8a8) 9 0x685d7d7a RPCRT4_receive_fragment+0x4c(Connection=0x112028, Header=0xb3e9c8, Payload=0xb3e908) [/home/dank/wine-git/dlls/rpcrt4/rpc_message.c:1363] in rpcrt4 (0x00b3e8c8) 10 0x685d7e72 RPCRT4_ReceiveWithAuth+0xf5(Connection=0x112028, Header=0xb3e9c8, pMsg=0x112418, auth_data_out=0xb3e9c4, auth_length_out=0xb3e9c0) [/home/dank/wine-git/dlls/rpcrt4/rpc_message.c:1396] in rpcrt4 (0x00b3e998) 11 0x685dae8e RPCRT4_io_thread+0xd5(the_arg=0x112028) [/home/dank/wine-git/dlls/rpcrt4/rpc_server.c:562] in rpcrt4 (0x00b3ea48) 12 0x7bc7f028 call_thread_func+0xb() in ntdll (0x00b3ea58) 13 0x7bc7f066 call_thread_entry_point+0x33(entry=0x685dadb8, arg=0x112028) [/home/dank/wine-git/dlls/ntdll/signal_i386.c:2499] in ntdll (0x00b3eb38) 14 0x7bc8694f start_thread+0x1c6(info=0x7ffb8fb8) [/home/dank/wine-git/dlls/ntdll/thread.c:405] in ntdll (0x00b3f398) 15 0x6818ae72 start_thread+0xd1() in libpthread.so.0 (0x00b3f498) Backtracing for thread 002a in process 000c (C:\windows\system32\services.exe): Backtrace: Backtracing for thread 0026 in process 000c (C:\windows\system32\services.exe): Backtrace: =>0 0x68000830 GLIBC_2+0x830() in ld-linux.so.2 (0x0083e358) 1 0x7bc83518 NTDLL_wait_for_multiple_objects+0x26c(count=0x1, handles=0x83e5f8, flags=0x4, timeout=(nil), signal_object=0x0(nil)) [/home/dank/wine-git/dlls/ntdll/sync.c:1124] in ntdll (0x0083e578) 2 0x7bc8361b NtWaitForMultipleObjects+0x67(count=0x1, handles=0x83e5f8, wait_all=0, aler
Re: msxml3: Move and Register xmlparser.idl in msxml3
On Thu, Sep 15, 2011 at 07:35, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Move and Register xmlparser.idl in msxml3 > > > Best Regards > Alistair Leslie-Hughes Howdy Alistair, You forgot to remove the include from include/Makefile.in, causing a build failure here: make[1]: Entering directory `/home/austin/wine-git/include' ../tools/makedep -C. -S.. -T.. activaut.idl activdbg.idl activscp.idl amstream.idl amvideo.idl asptlb.idl atliface.idl audioclient.idl audiopolicy.idl austream.idl bits.idl bits1_5.idl comcat.idl commoncontrols.idl control.idl cor.idl ctfutb.idl ctxtcall.idl d3d10.idl d3d10_1.idl d3d11.idl d3dcommon.idl ddstream.idl devicetopology.idl dimm.idl dispex.idl docobj.idl docobjectservice.idl downloadmgr.idl dxgi.idl endpointvolume.idl exdisp.idl fusion.idl gameux.idl hlink.idl htiframe.idl httprequest.idl iads.idl icftypes.idl iextag.idl imnact.idl imnxport.idl indexsrv.idl mediaobj.idl metahost.idl mimeinfo.idl mimeole.idl mlang.idl mmdeviceapi.idl mmstream.idl mscoree.idl msctf.idl msdadc.idl mshtmhst.idl mshtml.idl msinkaut.idl mstask.idl msxml.idl msxml2.idl msxml6.idl netcon.idl netfw.idl oaidl.idl objectarray.idl objidl.idl objsafe.idl ocidl.idl ocmm.idl oleacc.idl oledb.idl oleidl.idl optary.idl perhist.idl propidl.idl propsys.idl pstore.idl qedit.idl richole.idl sensevts.idl servprov.idl shdeprecated.idl shldisp.idl shobjidl.idl shtypes.idl strmif.idl structuredquerycondition.idl textstor.idl tom.idl unknwn.idl urlhist.idl urlmon.idl vmr9.idl wbemcli.idl wia_lh.idl wia_xp.idl wincodec.idl wine/itss.idl wine/svcctl.idl winsxs.idl wpcapi.idl wtypes.idl wuapi.idl xmllite.idl xmlparser.idl wine/winedxgi.idl stdole2.idl stdole2.tlb xmlparser.idl: No such file or directory make[1]: *** [depend] Error 1 make[1]: Leaving directory `/home/austin/wine-git/include' -- -Austin
Re: Something's rotten in git today...
Dan Kegel writes: > It might be just me, but I've seen five very strange test failures > today out of about 30 build/test runs. > Has anybody else noticed problems? It smells like the rpcrt4 change. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 13/19] vbscript: Added class functions parser implementation
On 09/15/11 18:38, Dan Kegel wrote:
Fails here under WINEDEBUG=warn-heap:
../../../tools/runtest -q -P wine -M vbscript.dll -T ../../.. -p
vbscript_test.exe.so run.c&& touch run.ok
wine: Unhandled page fault on read access to 0x at address
0x4004c1e4 (thread 0019), starting debugger...
Backtrace:
=>0 0x4004c1e4 add_class_function+0x29(ctx=0x33fad8,
class_decl=0x151dd4, decl=0x151dbc) [dlls/vbscript/parser.y:638]
1 0x4004b63e parser_parse+0xee6(ctx=0x33fad8) [dlls/vbscript/parser.y:294]
2 0x4004c3a2 parse_script+0xae(ctx=0x33fad8, code="...",
ret=0x33fbe8) [dlls/vbscript/compile.c:961]
4 0x40049685 VBScriptParse_ParseScriptText+0x12d(iface=0x125e5c,
pstrCode="...", pstrItemName=0x0(nil), punkContext=(nil),
pstrDelimiter=0x0(nil), dwSourceContextCookie=0, ulStartingLine=0,
dwFlags=0, pvarResult=(nil), pexcepinfo=(nil))
[dlls/vbscript/vbscript.c:554]
5 0x684b796d parse_script+0x32c(flags=0x8, script_str="...")
[dlls/vbscript/tests/run.c:683]
6 0x684b7e99 run_from_res+0x15b(name="lang.vbs")
[dlls/vbscript/tests/run.c:784]
7 0x684b845c run_tests+0x4eb() [dlls/vbscript/tests/run.c:841]
8 0x684b854c func_run+0x7a() [dlls/vbscript/tests/run.c:871]
9 0x684bb2d3 run_test+0x9e(name="run.c")
[dlls/vbscript/tests/../../../include/wine/test.h:556]
0x4004c1e4 add_class_function+0x29 [dlls/vbscript/parser.y:638] in
vbscript: movl 0x0(%eax),%eax
638 if(!strcmpiW(iter->name, decl->name)) {
Thanks for the report. It lacks initialization of a variable (that was
done in later, not yet sent patch). I've sent a fix.
Jacek
re: [PATCH 13/19] vbscript: Added class functions parser implementation
Fails here under WINEDEBUG=warn-heap:
../../../tools/runtest -q -P wine -M vbscript.dll -T ../../.. -p
vbscript_test.exe.so run.c && touch run.ok
wine: Unhandled page fault on read access to 0x at address
0x4004c1e4 (thread 0019), starting debugger...
Backtrace:
=>0 0x4004c1e4 add_class_function+0x29(ctx=0x33fad8,
class_decl=0x151dd4, decl=0x151dbc) [dlls/vbscript/parser.y:638]
1 0x4004b63e parser_parse+0xee6(ctx=0x33fad8) [dlls/vbscript/parser.y:294]
2 0x4004c3a2 parse_script+0xae(ctx=0x33fad8, code="...",
ret=0x33fbe8) [dlls/vbscript/compile.c:961]
4 0x40049685 VBScriptParse_ParseScriptText+0x12d(iface=0x125e5c,
pstrCode="...", pstrItemName=0x0(nil), punkContext=(nil),
pstrDelimiter=0x0(nil), dwSourceContextCookie=0, ulStartingLine=0,
dwFlags=0, pvarResult=(nil), pexcepinfo=(nil))
[dlls/vbscript/vbscript.c:554]
5 0x684b796d parse_script+0x32c(flags=0x8, script_str="...")
[dlls/vbscript/tests/run.c:683]
6 0x684b7e99 run_from_res+0x15b(name="lang.vbs")
[dlls/vbscript/tests/run.c:784]
7 0x684b845c run_tests+0x4eb() [dlls/vbscript/tests/run.c:841]
8 0x684b854c func_run+0x7a() [dlls/vbscript/tests/run.c:871]
9 0x684bb2d3 run_test+0x9e(name="run.c")
[dlls/vbscript/tests/../../../include/wine/test.h:556]
0x4004c1e4 add_class_function+0x29 [dlls/vbscript/parser.y:638] in
vbscript: movl 0x0(%eax),%eax
638 if(!strcmpiW(iter->name, decl->name)) {
On Thu, Sep 15, 2011 at 8:16 AM, wrote:
> This is an experimental automated build and test service.
> Please feel free to ignore this email while we work the kinks out.
>
> For more info about this message, see http://wiki.winehq.org/BuildBot
>
> The Buildbot has detected a failed build on builder runtests-heaptest while
> building Wine.
> Full details are available at:
> http://buildbot.kegel.com/builders/runtests-heaptest/builds/92 (though maybe
> not for long, as I'm still reinstalling the buildbot periodically while
> experimenting)
> BUILD FAILED: failed shell_3
>
> Errors:
> make: *** [run.ok] Error 5
>
>
Re: ole32/tests: Fix compilation on systems that don't support nameless unions.
Dan Kegel writes: > Also be a bit more uniform about using U() instead of .u when accessing > LowPart. .u is better. -- Alexandre Julliard julli...@winehq.org
Re: Something's rotten in git today...
Hey Dan, On 09/15/2011 02:02 AM, Dan Kegel wrote: > It might be just me, but I've seen five very strange test failures > today out of about 30 build/test runs. > Has anybody else noticed problems? > Does it happen if you try wine.git from before yesterday too? ~Maarten
Re: [PATCH] oleaut32: OLEPictureImpl_Load uses Seek(STREAM_SEEK_END) to find the stream length
On Thu, Sep 15, 2011 at 02:09:56PM +0200, Bernhard Loos wrote:
> ---
> dlls/oleaut32/olepicture.c | 148
> +-
> dlls/oleaut32/tests/olepicture.c | 16 ++---
> 2 files changed, 54 insertions(+), 110 deletions(-)
Did make check work for you even? Marvin does not like it at least.
This will break NonStatable streams, also seekability of streams can
not be assumed.
Ciao, Marcus
> diff --git a/dlls/oleaut32/olepicture.c b/dlls/oleaut32/olepicture.c
> index 8081785..725207f 100644
> --- a/dlls/oleaut32/olepicture.c
> +++ b/dlls/oleaut32/olepicture.c
> @@ -1324,15 +1324,13 @@ static HRESULT OLEPictureImpl_LoadAPM(OLEPictureImpl
> *This,
> */
> static HRESULT WINAPI OLEPictureImpl_Load(IPersistStream* iface, IStream
> *pStm) {
>HRESULThr;
> - BOOL headerisdata;
> - BOOL statfailed = FALSE;
> - ULONG xread, toread;
> - ULONG headerread;
> + ULONG xread, toread = 0;
>BYTE *xbuf;
>DWORD header[2];
>WORD magic;
> - STATSTG statstg;
>OLEPictureImpl *This = impl_from_IPersistStream(iface);
> + ULARGE_INTEGER end, start;
> + LARGE_INTEGER offset;
>
>TRACE("(%p,%p)\n",This,pStm);
>
> @@ -1348,104 +1346,56 @@ static HRESULT WINAPI
> OLEPictureImpl_Load(IPersistStream* iface, IStream *pStm)
> * At least in Visual Basic 6, resource streams, valid headers are
> *header[0] == "lt\0\0",
> *header[1] == length_of_stream.
> - *
> - * Also handle streams where we do not have a working "Stat" method by
> - * reading all data until the end of the stream.
> */
> - hr = IStream_Stat(pStm,&statstg,STATFLAG_NONAME);
> - if (hr != S_OK) {
> - TRACE("stat failed with hres %x, proceeding to read all data.\n",hr);
> - statfailed = TRUE;
> - /* we will read at least 8 byte ... just right below */
> - statstg.cbSize.QuadPart = 8;
> - }
> + offset.QuadPart = 0;
>
> - toread = 0;
> - headerread = 0;
> - headerisdata = FALSE;
>do {
> - hr = IStream_Read(pStm, header, 8, &xread);
> - if (hr != S_OK || xread!=8) {
> - ERR("Failure while reading picture header (hr is %x, nread is
> %d).\n",hr,xread);
> - return (hr?hr:E_FAIL);
> - }
> - headerread += xread;
> - xread = 0;
> -
> - if (!memcmp(&(header[0]),"lt\0\0", 4) && (statfailed || (header[1] +
> headerread <= statstg.cbSize.QuadPart))) {
> - if (toread != 0 && toread != header[1])
> - FIXME("varying lengths of image data (prev=%u curr=%u), only
> last one will be used\n",
> - toread, header[1]);
> - toread = header[1];
> - if (toread == 0) break;
> - } else {
> - if (!memcmp(&(header[0]), "GIF8", 4) || /* GIF header */
> - !memcmp(&(header[0]), "BM", 2) || /* BMP header */
> - !memcmp(&(header[0]), "\xff\xd8", 2) || /* JPEG header */
> - (header[0] == EMR_HEADER)|| /* EMF header */
> - (header[1] > statstg.cbSize.QuadPart)|| /* invalid size */
> - (header[1]==0)
> - ) {/* Found start of bitmap data */
> - headerisdata = TRUE;
> - if (toread == 0)
> - toread = statstg.cbSize.QuadPart-8;
> - else toread -= 8;
> - xread = 8;
> - } else {
> - FIXME("Unknown stream header magic: %08x\n", header[0]);
> - toread = header[1];
> - }
> - }
> - } while (!headerisdata);
> -
> - if (statfailed) { /* we don't know the size ... read all we get */
> - int sizeinc = 4096;
> - int origsize = sizeinc;
> - ULONG nread = 42;
> -
> - TRACE("Reading all data from stream.\n");
> - xbuf = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, origsize);
> - if (headerisdata)
> - memcpy (xbuf, header, 8);
> - while (1) {
> - while (xread < origsize) {
> - hr = IStream_Read(pStm,xbuf+xread,origsize-xread,&nread);
> - xread += nread;
> - if (hr != S_OK || !nread)
> - break;
> - }
> - if (!nread || hr != S_OK) /* done, or error */
> - break;
> - if (xread == origsize) {
> - origsize += sizeinc;
> - sizeinc = 2*sizeinc; /* exponential increase */
> - xbuf = HeapReAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, xbuf,
> origsize);
> - }
> - }
> - if (hr != S_OK)
> - TRACE("hr in no-stat loader case is %08x\n", hr);
> - TRACE("loaded %d bytes.\n", xread);
> - This->datalen = xread;
> - This->data= xbuf;
> - } else {
> - This->datalen = toread+(headerisdata?8:0);
> - xbuf = This->data = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY,
> This->datalen);
> - if (!xbuf)
> -
Re: [PATCH 06/19] vbscript: Added interp_new implementation
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=14262 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
Re: [PATCH 19/19] vbscript: Added stop statement semi-stub implementation
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=14271 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
Re: [PATCH 18/19] vbscript: Added this object to identifier lookup chanin
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=14270 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
Re: [PATCH 13/19] vbscript: Added class functions parser implementation
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=14266 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
Re: [PATCH 12/19] vbscript: Added function storage specifiers support
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=14265 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
Re: [PATCH 17/19] vbscript: Added interp_mcall implementation
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=14269 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
Re: [PATCH 04/19] vbscript: Added interp_set_ident implementation
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=14261 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
Re: [PATCH 01/19] vbscript: Added class parser implementation
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=14260 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
Re: [PATCH] oleaut32: OLEPictureImpl_Load uses Seek(STREAM_SEEK_END) to find the stream length
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=14259 Your paranoid android. === W2KPROSP4 (32 bit olepicture) === olepicture: unhandled exception c005 at 780109B3 === WXPPROSP3 (32 bit olepicture) === olepicture: unhandled exception c005 at 77C46FA3 === W2K3R2SESP2 (32 bit olepicture) === olepicture: unhandled exception c005 at 77BD7E23 === WVISTAADM (32 bit olepicture) === olepicture: unhandled exception c005 at 76F29B2B === W2K8SE (32 bit olepicture) === olepicture: unhandled exception c005 at 76149F09 === W7PRO (32 bit olepicture) === olepicture: unhandled exception c005 at 75CA9B60 === W7PROX64 (32 bit olepicture) === olepicture: unhandled exception c005 at 777A9B60 === W7PROX64 (64 bit olepicture) === Timeout
Re: pdh/tests: Some tests require that the user interface be in English. (try 2)
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=14256 Your paranoid android. === W2KPROSP4 (32 bit pdh) === pdh.c:157: Test failed: PdhAddCounterA failed 0xcbc4 pdh.c:204: Test failed: PdhAddCounterW failed 0xcbc4
Re: msi: Improve parsing of the package platform.
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=14255
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:6000: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
