September 2011 - Wine-Devel

Re: amd processors seem slow at running configure?

by David Kiefer

On 15.09.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? > > It might be related to frequency scaling. I have a Phenom II X4 945 and configure runs in 29 seconds, but only when using the performance governor. When using the default ondemand governor it runs in 59 seconds, similar to what Austin got. It would be interesting to know how the i7 fares when using the performance governor.

Sept. 16, 2011

Re: Proof of concept - The crashbot

by Austin English

On Fri, Sep 16, 2011 at 10:38, Dan Kegel <dank(a)kegel.com> wrote: > Hi Bruno, > it would of course be great. Check out > http://code.google.com/p/winetricks/source/browse/trunk/tests/winetricks-te… > for starters, we could just run that (or a subset of it) daily. > It's fairly reliable, as I ran it manually every week for a while > and weeded out a lot of flaky bits. > > When I get a chance, I'll try integrating that into buildbot. > - Dan > > p.s. As Henri mentioned, it's been on people's minds for years. > The graveyard is littered with previous attempts, e.g. > http://web.archive.org/web/20070209153523/http://www.cxtest.org/ > I think it's important to do the easy part first and not do anything fancy. You can see appinstall here: http://code.google.com/p/winezeug/source/browse/#svn%2Ftrunk%2Fappinstall which used a shell script to automate testing with AutoHotKey (checking for expected crashes was supported as well). Automated app testing is very useful, but at the others pointed out, it's quite a pain to get right and have it be reliable. That said, simply running an application and checking for a crash isn't that difficult, it's the more tedious testing of menus/input that get really nasty. And installation of apps that don't have a silent option is also annoying.. Good luck! Feel free to contact me privately if needed. -- -Austin

Sept. 16, 2011

Re: "make test" redux 2

by Stefan Dösinger

On Friday 16 September 2011 23:54:03 Dan Kegel wrote: > The rpct4 change seems seriously wrong, offhand, given > how widespread the breakage it sometimes causes is. > (A lot of tests seemed to think that the C:\ drive didn't exist.) There's hope that once the buildbot works well enough that Alexandre trusts it and doesn't commit patches a patch like this doesn't get in. And if we have multiple machines it's less likely that a patch that breaks randomly e.g. due to a buffer overrun goes by unnoticed.

Sept. 16, 2011

Re: "make test" redux 2

by Dan Kegel

On Fri, Sep 16, 2011 at 2:54 PM, Dan Kegel <dank(a)kegel.com> wrote: > Mercifully, this kind of breakage doesn't happen often, so I guess > I'm ok with doing local reverts when it does. I'm just worried that > I won't be able to get to it quickly enough, and the resulting barrage > of test failures will turn people off. I suppose when the daily git commit lands, I could run the test suite ten times over. That'd only take an extra hour. If any failures occur during the burn-in, I could have buildbot stop testing patches until the git test failure was worked around or fixed.

Sept. 16, 2011

Re: "make test" redux 2

by Dan Kegel

On Fri, Sep 16, 2011 at 2:31 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > I'm not going to revert patches, that would make a mess of the > history. Reverting is a serious event and should happen only when a > change is completely wrong, not when it happens to not be 100% correct > or to have some unwanted side effect. The rpct4 change seems seriously wrong, offhand, given how widespread the breakage it sometimes causes is. (A lot of tests seemed to think that the C:\ drive didn't exist.) > There are already many checks done before commit, and adding more checks > like you do is of course a very good idea. All together, that should > ensure that no committed patch can cause dramatic breakage. But there > will always be minor breakages, and flaky tests, and race conditions, > and buildbot must be able to deal with them gracefully, without > requiring me to scramble a revert. It's kind of hard to gracefully handle it when dozens of tests fail randomly because of a bad commit. Mercifully, this kind of breakage doesn't happen often, so I guess I'm ok with doing local reverts when it does. I'm just worried that I won't be able to get to it quickly enough, and the resulting barrage of test failures will turn people off. - Dan

Sept. 16, 2011

Re: "make test" redux 2

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > But sometimes bad patches don't fail during the few test runs > currently done, get committed, and then start causing unrelated > patches to fail randomly, poisoning future test runs until it the bug > is fixed or the bad patch reverted. > It would be nice if Alexandre reverted bad patches as soon as > the buildbot started going red, without waiting for his usual > daily batch of commits, and without waiting for someone to > fix the bad patch. (Maybe this can be discussed at wineconf.) I'm not going to revert patches, that would make a mess of the history. Reverting is a serious event and should happen only when a change is completely wrong, not when it happens to not be 100% correct or to have some unwanted side effect. There are already many checks done before commit, and adding more checks like you do is of course a very good idea. All together, that should ensure that no committed patch can cause dramatic breakage. But there will always be minor breakages, and flaky tests, and race conditions, and buildbot must be able to deal with them gracefully, without requiring me to scramble a revert. -- Alexandre Julliard julliard(a)winehq.org

Sept. 16, 2011

"make test" redux 2

by Dan Kegel

Wine's test suite is now nine years old, and thanks in large part to Ge's testbot, new tests tend to actually work on windows. There's a lot of passing tests at http://test.winehq.org, which is awesome. Wine developers routinely use it to avoid sending bad patches. And yet, some bad patches do get sent. Running all the incoming patches from wine-patches though the reliable subset of the tests automatically has been finding about one real bug a day. Sometimes I can warn the author soon enough that he can send a revised patch before the bad one is committed. Automated testing ftw! But sometimes bad patches don't fail during the few test runs currently done, get committed, and then start causing unrelated patches to fail randomly, poisoning future test runs until it the bug is fixed or the bad patch reverted. It would be nice if Alexandre reverted bad patches as soon as the buildbot started going red, without waiting for his usual daily batch of commits, and without waiting for someone to fix the bad patch. (Maybe this can be discussed at wineconf.) Right, so that's the story for keeping new bugs out of the tree. And then there are all the old bugs. Getting them fixed sometime would be nice; until then, the buildbot just skips known bad tests. Here are the tests that fail or crash sometimes for me when run normally on 32 bit systems. (This list is a lot bigger than the one I posted back in 2009, mostly because I'm running the tests a lot more, and noticing ones that only fail occasionally.) http://bugs.winehq.org/show_bug.cgi?id=28301 dlls/ddraw/tests/visual.ok http://bugs.winehq.org/show_bug.cgi?id=28257 dlls/kernel32/tests/pipe.ok http://bugs.winehq.org/show_bug.cgi?id=28220 dlls/kernel32/tests/process.ok http://bugs.winehq.org/show_bug.cgi?id=28295 dlls/mshtml/tests/htmldoc.ok http://bugs.winehq.org/show_bug.cgi?id=28290 dlls/shell32/tests/shelllink.ok http://bugs.winehq.org/show_bug.cgi?id=28323 dlls/urlmon/tests/protocol.ok http://bugs.winehq.org/show_bug.cgi?id=28108 dlls/urlmon/tests/url.ok http://bugs.winehq.org/show_bug.cgi?id=20149 dlls/user32/tests/static.ok http://bugs.winehq.org/show_bug.cgi?id=28038 dlls/wininet/tests/urlcache.ok http://bugs.winehq.org/show_bug.cgi?id=28102 dlls/ws2_32/tests/sock.ok And another handful that fail or crash sometimes for me when run with WINEDEBUG=warn+heap: http://bugs.winehq.org/show_bug.cgi?id=28260 dlls/dsound/tests/ds3d8.ok http://bugs.winehq.org/show_bug.cgi?id=28260 dlls/dsound/tests/ds3d.ok http://bugs.winehq.org/show_bug.cgi?id=28316 dlls/kernel32/tests/debugger.ok http://bugs.winehq.org/show_bug.cgi?id=28257 dlls/kernel32/tests/pipe.ok http://bugs.winehq.org/show_bug.cgi?id=28262 dlls/mshtml/tests/style.ok http://bugs.winehq.org/show_bug.cgi?id=28258 programs/cmd/tests/batch.ok There are also tests I don't run on the buildbot because they only pass on other systems with particular window managers or sound hardware or software: http://bugs.winehq.org/show_bug.cgi?id=8668 dlls/dsound/tests/ds3d8.ok http://bugs.winehq.org/show_bug.cgi?id=8668 dlls/dsound/tests/ds3d.ok http://bugs.winehq.org/show_bug.cgi?id=8668 dlls/dsound/tests/dsound8.ok http://bugs.winehq.org/show_bug.cgi?id=8668 dlls/dsound/tests/dsound.ok http://bugs.winehq.org/show_bug.cgi?id=28216 dlls/shell32/tests/shlfolder.ok http://bugs.winehq.org/show_bug.cgi?id=12053 dlls/user32/tests/input.ok http://bugs.winehq.org/show_bug.cgi?id=12053 dlls/user32/tests/msg.ok http://bugs.winehq.org/show_bug.cgi?id=12053 dlls/user32/tests/win.ok http://bugs.winehq.org/show_bug.cgi?id=28267 dlls/winhttp/tests/winhttp.ok http://bugs.winehq.org/show_bug.cgi?id=28109 dlls/winmm/tests/capture.ok http://bugs.winehq.org/show_bug.cgi?id=28071 dlls/winmm/tests/mci.ok http://bugs.winehq.org/show_bug.cgi?id=28048 dlls/winmm/tests/wave.ok More info at http://wiki.winehq.org/BuildBot - Dan

Sept. 16, 2011

Re: amd processors seem slow at running configure?

by Roderick Colenbrander

On Thu, Sep 15, 2011 at 8:35 PM, Dan Kegel <dank(a)kegel.com> 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? > > > The Llano APUs lack L3 cache which can make them quite a bit slower than AMD Phenom CPUs. Also make sure that your RAM really runs at high clock speeds. Roderick

Sept. 16, 2011

Re: ieframe/tests: Skip some tests on Windows if WebBrowser is not supported.

by Jacek Caban

On 09/16/11 15:42, Francois Gouget wrote: > On Fri, 16 Sep 2011, Jacek Caban wrote: > [...] >>> hres = CoCreateInstance(&CLSID_WebBrowser, NULL, >>> CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, >>> &IID_IUnknown, (void**)unk); >>> - ok_(__FILE__,line)(hres == S_OK, "Creating WebBrowser object failed: >>> %08x\n", hres); >>> + if (hres == REGDB_E_CLASSNOTREG) >>> + win_skip_(__FILE__,line)("WebBrowser is not supported\n"); > [...] >> The failure is valid here, it's the testbot that is not smart enough. The >> tested DLL is not present on WINNT, so the test should be skipped >> automatically, like winetest does. > Yes, that's why I used a wine_skip() rather than a skip(). I think this > approach is valid too. My understanding is that in theory > CLSID_WebBrowser could be provided by any other dll. So given that this > test makes no direct use of ieframes.dll (that is does not link with it > nor loads it at run time), that makes checking for the presence of > ieframes.dll a bit questionable. IEs older than 7 had WebBrowser control implemented in shdocvw.dll. We surely don't want to run tests on anything older than IE6. IE6 results very little value in this case, so I consider DLL presence check as a nice way of skipping tests on too old platforms and I've even stripped the code from no longer needed checks that you want to add when I was moving them from shdocvw to ieframe, In this case, skipping tests is really a job for testbot. Jacek

Sept. 16, 2011

re: Proof of concept - The crashbot

by Dan Kegel

Hi Bruno, it would of course be great. Check out http://code.google.com/p/winetricks/source/browse/trunk/tests/winetricks-te… for starters, we could just run that (or a subset of it) daily. It's fairly reliable, as I ran it manually every week for a while and weeded out a lot of flaky bits. When I get a chance, I'll try integrating that into buildbot. - Dan p.s. As Henri mentioned, it's been on people's minds for years. The graveyard is littered with previous attempts, e.g. http://web.archive.org/web/20070209153523/http://www.cxtest.org/ I think it's important to do the easy part first and not do anything fancy.

Sept. 16, 2011

Re: Proof of concept - The crashbot

by Henri Verbeet

On 16 September 2011 16:56, Seth Shelnutt <shelnutt2(a)gmail.com> wrote: > Personally I think automated application testing is the next major testing > platform for wine. Test suites are the most important, but application > testing can mean knowing when new software works in wine and from a user > standpoint of view more "interesting" and applicable than what test suites > are getting passed. > It's something we've been interested in for some time, but it's fairly hard to make it work in a reliable way.

Sept. 16, 2011

Re: Proof of concept - The crashbot

by Seth Shelnutt

You might be interested in looking at Appinstall by Austin English. He has done some great work on using autohotkey and doing application installs. I started a GSOC project that wasn't accepted last year to improve upon it. I've made improvements since then but I guess I never pushed it to my github. I'll see about pushing the changes I've made tonight, in the meantime here is my github of "apptester" [1]. I was working mostly with python and using bash for wpkg. wpkg helps to automate the installation of apps. For the actually testing I was still trying to find out a good way to test a gui in an automated sort of fashion. Never really find a easy way because windows menus aren't automation friendly. I also looked at adding some of MSAA or Microsoft UI Automation support to wine but never got very far. Personally I think automated application testing is the next major testing platform for wine. Test suites are the most important, but application testing can mean knowing when new software works in wine and from a user standpoint of view more "interesting" and applicable than what test suites are getting passed. -Seth Shelnutt [1]https://github.com/Shelnutt2/apptester On Fri, Sep 16, 2011 at 9:42 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi, I would like your opinion about a project I may start based on > BuildBot (if the Dan/license allows). > > It's named crashbot because it's intended to automate testing of > applications that crash in wine. The main goal is reduce the amount of > time wasted on retesting bugzilla applications that authors abandoned. > > It's intented to be as easy as this: > 1 - Add a new application by setting it's name, bug number and direct > download url; > 2 - Add requirements to run using winetricks; > 3 - Set the test schedule (interval in days/weeks between repetitions); > 4 - See the results in a web page which will automatically update; > 5 - Auto send an email if the application starts successfully. > > The crashbot will run in a tmpfs to avoid disk burning and will ever > run applications in a clean prefix. It would extract the downloaded > program if necessary. Wine would be recompiled daily based on latest > git. > > In the future I would like to add support to some sort of window > scripting with keyboard and mouse input so it can be used not only to > test startup crashs but any other kind of test (including the program > installation before run). I'm not targeting it to test games for now > because it would run in a very basic computer with an embedded video > board. > > Thanks in advance and apologies if this already exists or was > discussed previously. > > Best wishes, > Bruno > > -- > universe* god::bigbang (void); //and then it all began... > > >

Sept. 16, 2011

re: [2/3] pdh/tests: Make the test pass on Windows 2000.

by Francois Gouget

On Fri, 16 Sep 2011, Dan Kegel wrote: > Build fails here? > > ccache gcc -c -I. -I. -I../../../include -I../../../include > -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT > -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement > -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings > -Wpointer-arith -Wlogical-op -g -O0 -Werror -o propsys.o propsys.c > pdh.c: In function ‘test_PdhAddCounterA’: > pdh.c:134: error: ‘PDH_INVALID_PATH’ undeclared (first use in this function) > pdh.c:134: error: (Each undeclared identifier is reported only once > pdh.c:134: error: for each function it appears in.) > pdh.c: In function ‘test_PdhAddCounterW’: > pdh.c:183: error: ‘PDH_INVALID_PATH’ undeclared (first use in this function) > ../../../tools/make_ctests -o testlist.c propsys.c > make[1]: *** [pdh.o] Error 1 Ah, I missed that this patch depends on this macro from my other Pdh headers patch. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Sept. 16, 2011

re: [2/3] pdh/tests: Make the test pass on Windows 2000.

by Dan Kegel

Build fails here? ccache gcc -c -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O0 -Werror -o propsys.o propsys.c pdh.c: In function ‘test_PdhAddCounterA’: pdh.c:134: error: ‘PDH_INVALID_PATH’ undeclared (first use in this function) pdh.c:134: error: (Each undeclared identifier is reported only once pdh.c:134: error: for each function it appears in.) pdh.c: In function ‘test_PdhAddCounterW’: pdh.c:183: error: ‘PDH_INVALID_PATH’ undeclared (first use in this function) ../../../tools/make_ctests -o testlist.c propsys.c make[1]: *** [pdh.o] Error 1

Sept. 16, 2011

Re: ieframe/tests: Skip some tests on Windows if WebBrowser is not supported.

by Francois Gouget

On Fri, 16 Sep 2011, Jacek Caban wrote: [...] > > hres = CoCreateInstance(&CLSID_WebBrowser, NULL, > > CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > > &IID_IUnknown, (void**)unk); > > - ok_(__FILE__,line)(hres == S_OK, "Creating WebBrowser object failed: > > %08x\n", hres); > > + if (hres == REGDB_E_CLASSNOTREG) > > + win_skip_(__FILE__,line)("WebBrowser is not supported\n"); [...] > The failure is valid here, it's the testbot that is not smart enough. The > tested DLL is not present on WINNT, so the test should be skipped > automatically, like winetest does. Yes, that's why I used a wine_skip() rather than a skip(). I think this approach is valid too. My understanding is that in theory CLSID_WebBrowser could be provided by any other dll. So given that this test makes no direct use of ieframes.dll (that is does not link with it nor loads it at run time), that makes checking for the presence of ieframes.dll a bit questionable. Indead on my NT4 VM I do get a CLSID_WebBrowser object but various tests then fail. It appears the same thing happens on the W2KPROSP4 testbot VM. I presume that's because these Windows versions provided this object through some older dll that did not support everything. But it would be nice to have the tests detect that and win_skip(). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Sept. 16, 2011

Proof of concept - The crashbot

by Bruno Jesus

Hi, I would like your opinion about a project I may start based on BuildBot (if the Dan/license allows). It's named crashbot because it's intended to automate testing of applications that crash in wine. The main goal is reduce the amount of time wasted on retesting bugzilla applications that authors abandoned. It's intented to be as easy as this: 1 - Add a new application by setting it's name, bug number and direct download url; 2 - Add requirements to run using winetricks; 3 - Set the test schedule (interval in days/weeks between repetitions); 4 - See the results in a web page which will automatically update; 5 - Auto send an email if the application starts successfully. The crashbot will run in a tmpfs to avoid disk burning and will ever run applications in a clean prefix. It would extract the downloaded program if necessary. Wine would be recompiled daily based on latest git. In the future I would like to add support to some sort of window scripting with keyboard and mouse input so it can be used not only to test startup crashs but any other kind of test (including the program installation before run). I'm not targeting it to test games for now because it would run in a very basic computer with an embedded video board. Thanks in advance and apologies if this already exists or was discussed previously. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Sept. 16, 2011

Re: ieframe/tests: Some tests require that the user interface be in English. (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=14330 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3070: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3070: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3070: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3070: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3146: Test failed: Creating WebBrowser object failed: 80040154 === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2463: Test failed: expected GetOverridesKeyPath webbrowser.c:2467: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2468: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2077: Test failed: put_Resizable failed: 80004001 webbrowser.c:2078: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2082: Test failed: put_Resizable failed: 80004001 webbrowser.c:2083: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2463: Test failed: expected GetOverridesKeyPath webbrowser.c:2467: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2468: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:402: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2077: Test failed: put_Resizable failed: 80004001 webbrowser.c:2078: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2082: Test failed: put_Resizable failed: 80004001 webbrowser.c:2083: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2463: Test failed: expected GetOverridesKeyPath webbrowser.c:2467: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2468: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:455: Test failed: unexpected nCmdID 29 webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:2613: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2733: Test failed: expected TranslateUrl webbrowser.c:2734: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2735: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2741: Test failed: ReadyState = 1, expected 4 webbrowser.c:2565: Test failed: ReadyState = 1, expected 4 webbrowser.c:785: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:801: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:808: Test failed: ReadyState = 1, expected 4 webbrowser.c:600: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:600: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:603: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:607: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1503: Test failed: unexpected call GetOptionKeyPath webbrowser.c:351: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:785: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:785: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:785: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:785: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:455: Test failed: unexpected nCmdID 26 webbrowser.c:455: Test failed: unexpected nCmdID 29 webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:886: Test failed: ReadyState = 1, expected 4 webbrowser.c:1514: Test failed: unexpected call GetDropTarget webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:2613: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3106: Test failed: doc != doc2 webbrowser.c:600: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:600: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:603: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:607: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1503: Test failed: unexpected call GetOptionKeyPath webbrowser.c:351: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:455: Test failed: unexpected nCmdID 26 webbrowser.c:455: Test failed: unexpected nCmdID 29 webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:1514: Test failed: unexpected call GetDropTarget webbrowser.c:953: Test failed: unexpected call GetContainer webbrowser.c:503: Test failed: unexpected call webbrowser.c:2606: Test failed: expected TranslateUrl webbrowser.c:2613: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2826: Test failed: expected RequestUIActivate webbrowser.c:2918: Test failed: Got 0x80004002 webbrowser.c:3113: Test failed: doc != doc2 webbrowser.c:3013: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040C9B2

Sept. 16, 2011

Re: ieframe/tests: Don't crash if IWebBrowser2_get_LocationURL() fails.

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=14329 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3049: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3049: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3049: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3049: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3125: Test failed: Creating WebBrowser object failed: 80040154 === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2056: Test failed: put_Resizable failed: 80004001 webbrowser.c:2057: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2061: Test failed: put_Resizable failed: 80004001 webbrowser.c:2062: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:381: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2056: Test failed: put_Resizable failed: 80004001 webbrowser.c:2057: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2061: Test failed: put_Resizable failed: 80004001 webbrowser.c:2062: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2712: Test failed: expected TranslateUrl webbrowser.c:2713: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2714: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2720: Test failed: ReadyState = 1, expected 4 webbrowser.c:2544: Test failed: ReadyState = 1, expected 4 webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:780: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:787: Test failed: ReadyState = 1, expected 4 webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:582: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:586: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:590: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1482: Test failed: unexpected call GetOptionKeyPath webbrowser.c:330: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:434: Test failed: unexpected nCmdID 26 webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:865: Test failed: ReadyState = 1, expected 4 webbrowser.c:1493: Test failed: unexpected call GetDropTarget webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3085: Test failed: doc != doc2 webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:582: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:586: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:590: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1482: Test failed: unexpected call GetOptionKeyPath webbrowser.c:330: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:434: Test failed: unexpected nCmdID 26 webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:1493: Test failed: unexpected call GetDropTarget webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2585: Test failed: expected TranslateUrl webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2805: Test failed: expected RequestUIActivate webbrowser.c:2897: Test failed: Got 0x80004002 webbrowser.c:3092: Test failed: doc != doc2 webbrowser.c:2992: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040C9B2

Sept. 16, 2011

Re: ieframe/tests: Skip some tests on Windows if WebBrowser is not supported.

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=14328 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2056: Test failed: put_Resizable failed: 80004001 webbrowser.c:2057: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2061: Test failed: put_Resizable failed: 80004001 webbrowser.c:2062: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:381: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2056: Test failed: put_Resizable failed: 80004001 webbrowser.c:2057: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2061: Test failed: put_Resizable failed: 80004001 webbrowser.c:2062: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2442: Test failed: expected GetOverridesKeyPath webbrowser.c:2446: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2447: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2712: Test failed: expected TranslateUrl webbrowser.c:2713: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2714: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2720: Test failed: ReadyState = 1, expected 4 webbrowser.c:2544: Test failed: ReadyState = 1, expected 4 webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:780: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:787: Test failed: ReadyState = 1, expected 4 webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:582: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:586: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:590: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1482: Test failed: unexpected call GetOptionKeyPath webbrowser.c:330: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:764: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:434: Test failed: unexpected nCmdID 26 webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:865: Test failed: ReadyState = 1, expected 4 webbrowser.c:1493: Test failed: unexpected call GetDropTarget webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3085: Test failed: doc != doc2 webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:579: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:582: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:586: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:590: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1482: Test failed: unexpected call GetOptionKeyPath webbrowser.c:330: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:434: Test failed: unexpected nCmdID 26 webbrowser.c:434: Test failed: unexpected nCmdID 29 webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:1493: Test failed: unexpected call GetDropTarget webbrowser.c:932: Test failed: unexpected call GetContainer webbrowser.c:482: Test failed: unexpected call webbrowser.c:2585: Test failed: expected TranslateUrl webbrowser.c:2592: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2805: Test failed: expected RequestUIActivate webbrowser.c:2897: Test failed: Got 0x80004002 webbrowser.c:3092: Test failed: doc != doc2 webbrowser.c:2992: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040C9E2

Sept. 16, 2011

Re: ieframe/tests: Skip some tests on Windows if WebBrowser is not supported.

by Jacek Caban

On 09/16/11 15:25, Francois Gouget wrote: > --- > > This fixes this test on the WNT4WSSP6 testbot machine. > It also helps on my NT4 VM but one would not notice because there's no > ieframes dll so WineTest does not even try to run this test! > > dlls/ieframe/tests/webbrowser.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/dlls/ieframe/tests/webbrowser.c b/dlls/ieframe/tests/webbrowser.c > index a36c134..0506be6 100644 > --- a/dlls/ieframe/tests/webbrowser.c > +++ b/dlls/ieframe/tests/webbrowser.c > @@ -212,7 +212,10 @@ static HRESULT _create_WebBrowser(unsigned line, IUnknown **unk) > > hres = CoCreateInstance(&CLSID_WebBrowser, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > &IID_IUnknown, (void**)unk); > - ok_(__FILE__,line)(hres == S_OK, "Creating WebBrowser object failed: %08x\n", hres); > + if (hres == REGDB_E_CLASSNOTREG) > + win_skip_(__FILE__,line)("WebBrowser is not supported\n"); > + else > + ok_(__FILE__,line)(hres == S_OK, "Creating WebBrowser object failed: %08x\n", hres); > return hres; > } The failure is valid here, it's the testbot that is not smart enough. The tested DLL is not present on WINNT, so the test should be skipped automatically, like winetest does. Jacek

Sept. 16, 2011

Re: [PATCH 19/19] vbscript: Added do..while and do..until statements implementation

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=14325 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

Sept. 16, 2011

Re: [PATCH 18/19] vbscript: Added do until..loop statement implementation

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=14324 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

Sept. 16, 2011

Re: [PATCH 17/19] vbscript: Added support for exit do statement

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=14323 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

Sept. 16, 2011

Re: [PATCH 16/19] vbscript: Added do while..loop statement implementation

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=14322 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

Sept. 16, 2011

Re: [PATCH 15/19] vbscript: Added while..wend statement implementation

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=14321 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

Sept. 16, 2011