September 2011 - Wine-Devel

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

by Francois Gouget

On Fri, 16 Sep 2011, Jacek Caban wrote: [...] > 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. The problem is that the fact we want the ieframes.dll implementation and none other is absolutely not documented currently. Just relying on the test executable's name is insufficient imho, especially as it runs counter to the COM philosophy[1]. Similarly, relying on WineTest or Testbot behavior is insufficient in this case. So I think it owuld be much better if the test itself documented what its requirements are, either with a LoadLibrary() or with at least a trace or comment in the code. [1] That is, the fact that a piece of code tries to create a CLSID_WebBrowser object does not imply that it wants ieframes.dll or any other specific dll. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Sept. 18, 2011

Re: dpnet: return a TCP/IP provider in IDirectPlay8PeerImpl_EnumServiceProviders (try 3)

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=14371 Your paranoid android. === WNT4WSSP6 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BC === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BC

Sept. 18, 2011

re: msxml3: Fix printing NULL strings

by Francois Gouget

On Sun, 18 Sep 2011, Dan Kegel wrote: [...] > $ ccache gcc -c -I. -I. -I../../include -I../../include > -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ > -DCOM_NO_WINDOWS_H -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 element.o element.c > > cc1: warnings being treated as errors > element.c: In function ‘variant_from_dt’: > element.c:666: error: pointer targets in passing argument 1 of > ‘debugstr_a’ differ in signedness > ../../include/wine/debug.h:259: note: expected ‘const char *’ but > argument is of type ‘const xmlChar *’ I'm not sure how to fix that. 1) I could add (char*) casts everywhere but that's quite ugly. 2) I could create a macro. Probably uglier. 3) Or I could create a debugstr_ua() that takes unsigned chars. (And calls debugstr_a() with a cast) I'm kind of leaning towards the third option. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

Sept. 18, 2011

Re: quartz/tests: Skip some tests if not allowed to register filters.

by Francois Gouget

On Sun, 18 Sep 2011, Marvin wrote: [...] > === WNT4WSSP6 (32 bit filtermapper) === > filtermapper.c:93: Test failed: CoCreateInstance failed with 80040154 > filtermapper.c:230: Test failed: CoCreateInstance failed with 80040154 > filtermapper.c:344: Test failed: CoCreateInstance failed with 80040154 > filtermapper.c:402: Test failed: CoCreateInstance failed with 80040154 These errors are unrelated to my patch. This VM simply does not have Quartz installed (REGDB_E_CLASSNOTREG) as is confirmed by the 'n/a' wtb-wnt4wssp6 WineTest results. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Sept. 18, 2011

Re: shell32: Don't dereference NULL pointers when tracing.

by Octavian Voicu

On Sun, Sep 18, 2011 at 8:37 PM, Francois Gouget <fgouget(a)free.fr> wrote: > + TRACE("-- vmode %#x, flags %#x", view_params->pfs->ViewMode, view_params->pfs->fFlags); > + if (view_params->prcView) > + TRACE(", left %d, top %d, right %d, bottom %d", view_params->prcView->left, > + view_params->prcView->top, view_params->prcView->right, view_params->prcView->bottom); > + TRACE("\n"); I think it would look much nicer with wine_dbgstr_rect and it can handle NULL pointers. Octavian

Sept. 18, 2011

Re: [PATCH] cmd: Avoid rereading batch file for every call/goto executed (try 3)

by Octavian Voicu

2011/9/18 Dan Kegel <dank(a)kegel.com>: > 2011/9/18 Dan Kegel <dank(a)kegel.com>: >> Don't let this one languish - it makes a huge difference for me! > > I should mention: with your latest additions to the cmd tests, > time to run the cmd tests is starting to go off the cliff, > and is now above four minutes... but with your efficiency > patch, it only takes four seconds. I have a quick fix for you, which did wonders for me. Initially I also had timeouts on every test, now they all pass. The ideas is to run the tests from an empty directory. The commands that recurse into subdirectories run much faster if they don't have a lot of subdirectories to search. Of course, the label cache patch seems to do even more wonders :) Octavian

Sept. 18, 2011

re: msxml3: Fix printing NULL strings

by Dan Kegel

Hi Francois, your patch has a signedness problem which makes -Werror unhappy. (We could disable signedness warnings, but since we don't currently have any, it's nice to keep them out of the tree...) Here's the log from the buildbot: $ ccache gcc -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -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 element.o element.c cc1: warnings being treated as errors element.c: In function ‘variant_from_dt’: element.c:666: error: pointer targets in passing argument 1 of ‘debugstr_a’ differ in signedness ../../include/wine/debug.h:259: note: expected ‘const char *’ but argument is of type ‘const xmlChar *’ element.c: In function ‘element_get_dt’: element.c:732: error: pointer targets in passing argument 1 of ‘debugstr_a’ differ in signedness ../../include/wine/debug.h:259: note: expected ‘const char *’ but argument is of type ‘const xmlChar *’ element.c: In function ‘domelem_put_nodeTypedValue’: element.c:789: error: pointer targets in passing argument 1 of ‘debugstr_a’ differ in signedness ../../include/wine/debug.h:259: note: expected ‘const char *’ but argument is of type ‘const xmlChar *’ element.c: In function ‘domelem_put_dataType’: element.c:937: error: pointer targets in passing argument 1 of ‘debugstr_a’ differ in signedness ../../include/wine/debug.h:259: note: expected ‘const char *’ but argument is of type ‘const xmlChar *’ make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/msxml3' make[1]: *** [element.o] Error 1 make: *** [dlls/msxml3] Error 2

Sept. 18, 2011

Re: Unimplemented function?

by Luis Carlos Busquets Pérez

Thanks Maarten. Your tip solved the issue. I wonder in any case if this should make rethink wine strategy and instead of forwarding funcs to a MS-name dll, depending on the API wine dlls could b e created. e.g. msvcrt.dll, msvr71.dll, msvcr80.dll, msvcr90.dll, ... --> winecr Other APIs could also be considered such as the long spoken d3dx: d3dx9_36.dll, d3dx9_37.dll, d3dx9_38.dll ...d3dx10_43.dll, d3dx10_44.dll ... --> wined3dx msvcp... --> winecp msxml2.dll, msxml3.dll, msxml4.dll ... --> winexml Luis

Sept. 18, 2011

Re: quartz/tests: Skip some tests if not allowed to register filters.

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=14367 Your paranoid android. === WNT4WSSP6 (32 bit filtermapper) === filtermapper.c:93: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:230: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:344: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:402: Test failed: CoCreateInstance failed with 80040154

Sept. 18, 2011

Re: [PATCH] cmd: Avoid rereading batch file for every call/goto executed (try 3)

by Frédéric Delanoy

2011/9/18 Dan Kegel <dank(a)kegel.com>: > 2011/9/18 Dan Kegel <dank(a)kegel.com>: >> Don't let this one languish - it makes a huge difference for me! > > I should mention: with your latest additions to the cmd tests, > time to run the cmd tests is starting to go off the cliff, > and is now above four minutes... but with your efficiency > patch, it only takes four seconds. Sent a cleaned up version (try 3) Not sure AJ will accept it though, since it seems he wanted a "batch file reading method" overhaul first. Frédéric

Sept. 18, 2011

Re: [PATCH] cmd: Avoid rereading batch file for every call/goto executed (try 3)

by Dan Kegel

2011/9/18 Dan Kegel <dank(a)kegel.com>: > Don't let this one languish - it makes a huge difference for me! I should mention: with your latest additions to the cmd tests, time to run the cmd tests is starting to go off the cliff, and is now above four minutes... but with your efficiency patch, it only takes four seconds.

Sept. 18, 2011

Update on testbot

by Maarten Lankhorst

Hi all, I moved the windows 7 x64 vm with sp1 applied to the base pool now. This means that all submitted patches will be run on that vm as well. The original win7 vm is still available under its own name. Since all tests pass on that according to winehq tests I'm keeping it in the base pool. I hope to see all tests on the new vm fixed as well. They mostly appear to be related to the ie9 update, but msctf:inputprocessor and msi:install fail as well. ~Maarten

Sept. 18, 2011

Creating register Resource.

by Alistair Leslie-Hughes

Hi, I'm attempting to create a RES file from the xmlparser.idl file. After I modify the Makefile with IDL_R_SRCS = xmlparser.idl The .res file is created, but no register information is generated. Have I missed something? Best Regards Alistair Leslie-Hughes

Sept. 18, 2011

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

by Octavian Voicu

On Fri, Sep 16, 2011 at 2:30 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- a/dlls/vbscript/compile.c > +++ b/dlls/vbscript/compile.c > static HRESULT compile_while_statement(compile_ctx_t *ctx, while_statement_t *stat) > { > - unsigned start_addr; > + unsigned start_addr, prev_label; ... > + if(stat->stat.type != STAT_WHILE) { > + prev_label = ctx->while_end_label; > + if((ctx->while_end_label = alloc_label(ctx)) == -1) > + return E_OUTOFMEMORY; > + } ... > + if(stat->stat.type != STAT_WHILE) { > + label_set_addr(ctx, ctx->while_end_label); > + ctx->while_end_label = prev_label; > + } Hello, This patch introduces a compile warning (gcc 4.5.2, both x86 and amd64): ../compile.c:489:26: warning: ‘prev_label’ may be used uninitialized in this function While I can see there's no actual problem, how can we shut the compiler's mouth? It may even be the case that if we just put a prev_label = 0 initializer, static analyzers will start complaining it's a useless assignment. Octavian

Sept. 18, 2011

Re: Unimplemented function?

by Maarten Lankhorst

Hey, On 09/18/2011 12:52 PM, Luis Carlos Busquets Pérez wrote: > It seems that there is a regression in wine 1.3.28. Before bi-secting, I woul dlike to understand how that can happen. Apparently PlaChessV5.exe crashes due to: > > wine: Call from 0x68215ca8 to unimplemented function msvcrt.dll._snwprintf_s, aborting > > > but when I look at the spec file, the function is defined: > > @ varargs _snwprintf_s(ptr long long wstr) MSVCRT__snwprintf_s > > and it exists in wcs.c > > How is it that them it results as undefined? Are you using a native msvcrt dll? ~Maarten

Sept. 18, 2011

Unimplemented function?

by Luis Carlos Busquets Pérez

It seems that there is a regression in wine 1.3.28. Before bi-secting, I woul dlike to understand how that can happen. Apparently PlaChessV5.exe crashes due to: wine: Call from 0x68215ca8 to unimplemented function msvcrt.dll._snwprintf_s, aborting but when I look at the spec file, the function is defined: @ varargs _snwprintf_s(ptr long long wstr) MSVCRT__snwprintf_s and it exists in wcs.c How is it that them it results as undefined? Luis

Sept. 18, 2011

Re: [wine-devel] re: [SOLVED] [PATCH]Where is the best place to report a fscanf bug found under wine-1.3.27?

by Alan W. Irwin

On 2011-08-30 13:25-0700 Alan W. Irwin wrote: > On 2011-08-30 08:33-0700 Dan Kegel wrote: > >>> Today I discovered .. that the scanf family of functions was >>> introducing float (32-bit floating-point) noise into double (64-bit >>> floating-point) results. >> >> I see it here, too: >> >> $ sudo apt-get install mingw32 >> $ i586-mingw32msvc-gcc test_fscanf.c >> $ echo "1.1e+01 >> 1.1e+00 >> 1.1e-01 >> 1.1e-02 >> 1.1e-03 >> 1.1e-04" | ~/wine-git/wine a.exe >> 1.10000000000000000e+001 >> 1.10000000000000009e+000 >> 1.10000001639127737e-001 >> 1.10000003278255491e-002 >> 1.10000004917383261e-003 >> 1.10000006556511075e-004 >> >> You can work around it with 'winetricks vcrun6', after which the test >> program outputs: >> 1.10000000000000000e+001 >> 1.10000000000000010e+000 >> 1.10000000000000000e-001 >> 1.09999999999999990e-002 >> 1.10000000000000010e-003 >> 1.10000000000000000e-004 >> >> So the problem is in wine's msvcrt.dll. >> >> You could narrow it down further by printing out the raw byte strings >> for the numbers >> and then sprinking that printout through the path from when scanf is >> called to where printf returns. >> (Or, I suppose, step through it with a debugger instead.) >> >> But the best place to report the bug is http://bugs.winehq.org > > Hi Dan: > > Thanks for these hints. It was good to know of that workaround > involving downloading a Microsoft library to replace the one from wine > in case I needed it. However, I prefer a direct fix if possible so I > looked further and finally found the code in question in the > _FUNCTION_ routine in wine-1.3.27/dlls/msvcrt/scanf.h. Sure enough it > has an inappropriate float in it which appears to be the source of the > trouble. > > Therefore, I tried this patch: > > --- scanf.h_original 2011-08-30 12:35:25.000000000 -0700 > +++ scanf.h 2011-08-30 12:36:23.000000000 -0700 > @@ -346,7 +346,7 @@ > /* handle exponent */ > if (width!=0 && (nch == 'e' || nch == 'E')) { > int exponent = 0, negexp = 0; > - float expcnt; > + double expcnt; > nch = _GETC_(file); > if (width>0) width--; > /* possible sign on the exponent */ > > rebuilt wine-1.3.27, and I now have this result: > > bash.exe-3.1$ echo "1.1e+01 > 1.1e+00 > 1.1e-01 > 1.1e-02 > 1.1e-03 > 1.1e-04" | ./a.exe > 1.10000000000000000e+001 > 1.10000000000000009e+000 > 1.10000000000000001e-001 > 1.10000000000000011e-002 > 1.10000000000000028e-003 > 1.10000000000000031e-004 > Hi Dan: Subsequently, I went a lot deeper into this because I had a more rigourous test application that showed the above patch (even if using the proper type of long double rather than double) is still not good enough. Details (including new patch and new test application) are at http://bugs.winehq.org/show_bug.cgi?id=28422. Here is the unpatched and patched Wine result for the new test code for one input number: bash.exe-3.1$ echo "1.1e-30" |./a.exe 1.1e-30 is input string 1.1000004917384256455392e-030 = 3f9b64f8772f16505258 is long double value 1.1000004917384256198806e-030 = 39b64f8772f16505 is double value 1.1000004917384e-030: 13: 1.1000009834770454030908e-030 = 39b64f881a45deaf 1.10000049173843e-030: 14: 1.1000009834770755310078e-030 = 39b64f881a45df5b 1.100000491738426e-030: 15: 1.1000009834770715022747e-030 = 39b64f881a45df44 1.1000004917384256e-030: 16: 1.1000009834770711519501e-030 = 39b64f881a45df42 1.10000049173842562e-030: 17: 1.1000009834770711519501e-030 = 39b64f881a45df42 bash.exe-3.1$ echo "1.1e-30" |./a.exe 1.1e-30 is input string 1.0999999999999999999835e-030 = 3f9b64f86cb9cefaf7a0 is long double value 1.0999999999999999165078e-030 = 39b64f86cb9cefaf is double value 1.1000000000000e-030: 13: 1.0999999999999999165078e-030 = 39b64f86cb9cefaf 1.10000000000000e-030: 14: 1.0999999999999999165078e-030 = 39b64f86cb9cefaf 1.100000000000000e-030: 15: 1.0999999999999999165078e-030 = 39b64f86cb9cefaf 1.0999999999999999e-030: 16: 1.0999999999999999165078e-030 = 39b64f86cb9cefaf 1.09999999999999992e-030: 17: 1.0999999999999999165078e-030 = 39b64f86cb9cefaf The latter patched result is in exact agreement with the corresponding Linux result except for the 3-digit exponents. As a result of this patch (to wine-1.3.26, but wine-1.3.28 has the same numerically imprecise scanf code so the patch will apply there as well), conversion of JPL ascii ephemeride data by the ephcom-2.0.2 software to double internal form for 1.5GBytes of doubles gives exact agreement between the Wine platform and Linux platform results for all but 0.04 per cent of the doubles Furthermore, those differing ones only disagree at the relative level of 1.e-16). This is the result you would expect if the Linux and (patched) Wine scanf flipped the last bit of the 80-bit long double number internal storage for the converted result in opposite ways most of the time. That bit flip would propagate to a differently rounded double result (which has 11 bits less in the hidden bit mantissa) roughly 0.04 per cent (~ 1/2^11) of the time in good agreement with what is observed. I am extremely happy with that detailed comparison which goes far beyond the single-number (or few number) comparisons you get with the above test routine. I don't want to get much deeper involved in Wine development because I have my own free software projects (such as ephcom) to develop and release. But I do feel this is an extremely important bug fix for Wine's version of msvcrt.dll since the scanf family of functions is so fundamental. Therefore, I hope you will act as a conscience/fix advocate for the Wine development team to make sure this numerical precision fix for the scanf family of routines in msvcrt.dll gets into the next Wine release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Sept. 17, 2011

Re: [po]updated korean resource(2011-09-16)

by Francois Gouget

> #: attrib.rc:47 > -#, fuzzy > msgid "" > "ATTRIB - Displays or changes file attributes.\n" > "\n" The reason why this one was fuzzy is that the indentation changed. However the translation's indentation has not be updated (which might possibly be ok for Korean), and it also seems to be pretty inconsistent (e.g. between the +/- lines and the R/A/etc ones. Also the '[drive:]' should probably really be indented. #: cmd.rc:288 -#, fuzzy msgid "" "CMD built-in commands are:\n" "ASSOC\t\tShow or modify file extension associations\n" The translation is missing the XCOPY line (it's hard to spot in the middle of all these lines). Maybe I should add translator comments when I mark a translation as fuzzy. This way the real translator would not have to puzzle over what caused the string to be marked as fuzzy. I have not been doing it because I worry they may be tricky to remove with some PO editors (but maybe my fears are unfounded). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Sept. 17, 2011

Re: [wine-devel] Re: Severe startup latencies for Windows applications run under wine

by Henri Verbeet

On 17 September 2011 20:34, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > In sum, from my perspective it is important for the Wine developers to > figure out exactly what the issue is and deal with it. 0.5-second Did anyone look into writing to /proc/pid/mem like I mentioned? Aside from perhaps the kernel version requirement this should be trivial to test. (Untested patch attached.)

Sept. 17, 2011

Re: [wine-devel] Re: Severe startup latencies for Windows applications run under wine

by Alan W. Irwin

On 2011-09-01 01:25+1000 Ben Peddell wrote: > On 31/08/2011 3:12 AM, Dan Kegel wrote: >> Try oprofile instead. >> >> ( A really old intro is at >> http://www.winehq.org/wwn/249#oprofile%20&%20Wine ) >> > > Using oprofile, testing 500 iterations of ExitProcess.exe with > msys-bash under wine: > > About 2/3 of the active processor time was in wineserver. > About 90% of that was spent in the kernel. > At least 50% of that time was spent in code related related to > ptrace(), which is ultimately called by > wineserver::write_process_memory(). > > The other 1/3 of the active processor time was in wine-preloader. > About 70% of that was spent in the kernel. > > 500 iterations took about 100s to complete at about 100% usage of 1 > CPU core. > > msys-bash uses WriteProcessMemory() to copy 500kB during an emulated > fork. This equates to about 125000 ptrace(PTRACE_POKEDATA,...) > syscalls, each of which takes about 0.8us on linux 2.6.38. > Hi Ben: Let me remind you and others here why I am so interested in these results. I am a strong advocate of free software on all platforms (not just Linux) so I went out of my way to make sure my recent ephcom-2.0.2 release built and gave good test results on MinGW/MSYS/Wine (the only Windows platform accessible to me). And that complete success on one Windows platform was confirmed by somebody else on a MinGW/MSYS/Microsoft Windows XP platform. However, the 0.5-second command startup latency under Wine makes software builds under MinGW/MSYS/Wine extraordinarily inconvenient. The problem is that build systems such as autotools and cmake (and presumably the rest as well) all break down the configuration task into many tiny tasks and similarly for the build itself under make. So when each of those tiny tasks take 0.5 seconds to complete the result is an extraordinary slowdown of the build. ephcom-2.0.2 is actually a pretty simple package so this wasn't too bad an issue in that case, but to test my build environment on MinGW/MSYS/wine, I recently attempted to build cmake (a C++ application in its own right that can be built using the windows binary version of cmake). That build was a success, but the whole build took more than an hour (as opposed to ~10 minutes under Linux). (Much) worse, yet, that hour constituted a denial of service attack on the Linux box underneath (and the same for the ephcom-2.0.2 build although substantially shorter duration in that case). During that time everything on the Linux desktop slowed to a crawl. For example, in a (pysol) Linux solitaire game I attempted, each card dealt took about a second (!) to complete. Switching from one desktop to another took seconds as well. The "top" application showed that whatever resource that the build under wine was consuming was not accessible to "top"; the cpu's were idle (virtually 100 per cent idle time), there was negligible wait time, and there was nothing obviously bad in the memory use. (These results were all with Linux kernel "Linux raven 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64 GNU/Linux" from Debian squeeze.) I am aware that you can build Windows software directly from Linux, but I am not going to use that alternative because for potential users of my software on all Windows platforms I need to test the build system of my software in a realistic Windows environment, and Wine provides that for me. Thus, despite the current horrible inconvenience I am going to stick with attempting to build software under Wine. Nevertheless, I think until this command startup latency under Wine (and especially the corresponding denial of service attack on Linux underneath) is reduced, most developers will avoid as much as possible attempting to build their packages under Wine. In sum, from my perspective it is important for the Wine developers to figure out exactly what the issue is and deal with it. 0.5-second command startup latencies are just not acceptable for a general platform. So where do we stand in that effort to find a solution? From above, your "500 iterations took about 100s" equates to a 0.2 second component of the command start-up latency that you have identified. And WriteProcessMemory() requiring 125000 syscalls(a)0.8us = 0.1 seconds just to copy 500kB sounds really bad. Have you opened a bug report to keep track of your results? If so, I would like to add my own timing results there. If not, shall I open a bug report for my timing results that you can add to? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Sept. 17, 2011

Re: Proof of concept - The crashbot

by Scott Ritchie

On 09/16/2011 08:16 AM, Henri Verbeet wrote: > 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. > > I think it's slightly easier to do the inverse -- automate applications to make sure they don't crash in future versions. I'm going to tackle something similar on the daily Ubuntu builds with winetricks' included selftest once Launchpad starts building them again. Thanks, Scott Ritchie

Sept. 17, 2011

Re: amd processors seem slow at running configure?

by Ben Klein

On 17 September 2011 09:29, Dan Kegel <dank(a)kegel.com> wrote: > On Fri, Sep 16, 2011 at 3:34 PM, David Kiefer <hevanen(a)googlemail.com> wrote: >> On 15.09.2011 21:35, Dan Kegel wrote: >>> My new AMD a8-3850 takes 77 seconds to run wine's configure script. >> >> 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. > > Good call! After doing > for cpu in `seq 0 3` do; sudo cpufreq-set -g performance -c $cpu; done > the a8-3850 runs configure in 37 seconds! Handy tip, Dan. Thanks :)

Sept. 17, 2011

Re: amd processors seem slow at running configure?

by Dan Kegel

On Fri, Sep 16, 2011 at 4:29 PM, Dan Kegel <dank(a)kegel.com> wrote: > Good call! After doing > for cpu in `seq 0 3` do; sudo cpufreq-set -g performance -c $cpu; done > the a8-3850 runs configure in 37 seconds (instead of 67)! > >> It would be interesting to know how the i7 fares when using the >> performance governor. > > On the i7, after doing "./configure" once to warm up, > ondemand gives 31 seconds, performance gives 23 seconds. > So it's not AMD-specific. > 'conservative' gives 26 seconds, halfway between the two. my q9300 isn't affected by this much; either way, it takes 32 to 37 seconds to run configure there.

Sept. 16, 2011

Re: amd processors seem slow at running configure?

by Dan Kegel

On Fri, Sep 16, 2011 at 3:34 PM, David Kiefer <hevanen(a)googlemail.com> wrote: > On 15.09.2011 21:35, Dan Kegel wrote: >> My new AMD a8-3850 takes 77 seconds to run wine's configure script. > > 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. Good call! After doing for cpu in `seq 0 3` do; sudo cpufreq-set -g performance -c $cpu; done the a8-3850 runs configure in 37 seconds! > It would be interesting to know how the i7 fares when using the > performance governor. On the i7, after doing "./configure" once to warm up, ondemand gives 31 seconds, performance gives 23 seconds. So it's not AMD-specific. 'conservative' gives 26 seconds, halfway between the two. - Dan

Sept. 16, 2011

Re: Something's rotten in git today...

by Austin English

On Thu, Sep 15, 2011 at 13:55, Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel <dank(a)kegel.com> wrote: >> On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos >> <bernhardloos(a)googlemail.com> 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 >> FWIW, on my local buildbot (debain testing 32-bit), the following tests have been randomly failing lately: kernel32/thread rpcrt4/server setupapi/install user32/menu user32/edit the user32 failures are likely flakiness, but the others may be related to this patch. I'm updating now to revert that patch and will see if that helps. Results are at http://austin987.dyndns.org:8010/ for now, for those curious. Once sorted out, will join main buildbot farm. -- -Austin

Sept. 16, 2011