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

Re: [PATCH 2/5] ddraw: Get rid of the surface implementation switching code.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > Despite what the comment says, switching the implementation of an already > created surface isn't so straightforward. > --- > dlls/ddraw/ddraw.c | 179 +-------------------------------------------- > dlls/ddraw/surface.c | 25 ------- > dlls/wined3d/swapchain.c | 4 +- > include/wine/wined3d.h | 1 - > 4 files changed, 6 insertions(+), 203 deletions(-) This one is causing crashes on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so ../../../../wine/dlls/d3d8/tests/buffer.c && touch buffer.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x2b631b0deede (thread 0021), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00002b631b0deede). Register dump: rip:00002b631b0deede rsp:000000000023f3a0 rbp:000000000023f45a eflags:00010246 ( R- -- I Z- -P- ) rax:0000000000000001 rbx:0000000000000000 rcx:0000000000000018 rdx:000000000023f459 rsi:000000000023f45a rdi:0000000000000000 r8:000000000023f45c r9:000000000023f45b r10:000000000023f45c r11:000000000023f330 r12:000000000023f459 r13:0000000000000000 r14:000000000003b5e0 r15:00002b631b0f00e0 Stack dump: 0x000000000023f3a0: 0000000000000000 0000000000000094 0x000000000023f3b0: 0000000000032ed0 0000000000000094 0x000000000023f3c0: 0000000000032ed0 000000000003e9f0 0x000000000023f3d0: 0000000000000000 00002b631b0307df 0x000000000023f3e0: ffffffffffffffff ffffff00ffffffff 0x000000000023f3f0: 0000000000202020 0000000020000000 0x000000000023f400: 0000000000000000 00000000ffffff00 0x000000000023f410: 0000000000000254 0000000000000000 0x000000000023f420: 0000000000000000 0000000000000000 0x000000000023f430: 0000000000000000 0000000000000000 0x000000000023f440: 0000000000000000 0000000000000000 0x000000000023f450: 5b5b5b5b5b5b5b5b 0808080018000020 Backtrace: =>0 0x00002b631b0deede getDepthStencilBits+0x2e(format=(nil), depthSize="", stencilSize="") [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/utils.c:2598] in wined3d (0x000000000023f45a) 1 0x00002b631b0307df context_choose_pixel_format+0xfe(device=0x3e9f0, hdc=0x254, color_format=0x3b5e0, ds_format=(nil), auxBuffers=0, findCompatible=0) [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/context.c:1139] in wined3d (0x0000000000032ed0) 2 0x00002b631b034b79 context_create+0xc8(swapchain=0x58b80, target=0x358f0, ds_format=(nil)) [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/context.c:1350] in wined3d (0x0000000000032ed0) 3 0x00002b631b0d297b swapchain_get_context+0x7a(swapchain=0x58b80) [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/swapchain.c:1179] in wined3d (0x00000000000358f0) 4 0x00002b631b03a155 context_acquire+0x314(device=0x3e9f0, target=0x358f0) [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/context.c:2455] in wined3d (0x00000000000358f0) 5 0x00002b631b047858 wined3d_device_init_3d+0x497(device=0x3e9f0, present_parameters=0x23f810) [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/device.c:1335] in wined3d (0x0000000000032ed0) 6 0x00002b631add142a device_init+0x1b9(device=0x36710, parent=0x2f380, wined3d=0x32eb0, adapter=<is not available>, device_type=<is not available>, focus_window=(nil), flags=0x40, parameters=0x23fae0) [/home/julliard/wine/build/obj-elf64/dlls/d3d8/../../../wine/dlls/d3d8/device.c:3112] in d3d8 (0x000000000023fae0) 7 0x00002b631add194b IDirect3D8Impl_CreateDevice+0x10a(iface=0x2f380, adapter=0, device_type=D3DDEVTYPE_HAL, focus_window=(nil), flags=0x40, parameters=0x23fae0, device=0x23fb38) [/home/julliard/wine/build/obj-elf64/dlls/d3d8/../../../wine/dlls/d3d8/directx.c:371] in d3d8 (0x0000000000036710) 8 0x00002b6316db08d7 func_buffer+0x196() [/home/julliard/wine/build/obj-elf64/dlls/d3d8/tests/../../../../wine/dlls/d3d8/tests/buffer.c:61] in d3d8_test (0x000000000023fb38) 9 0x00002b6316dd06c7 run_test+0x126(name="../../../../wine/dlls/d3d8/tests/buffer.c") [/home/julliard/wine/build/obj-elf64/dlls/d3d8/tests/../../../../wine/include/wine/test.h:556] in d3d8_test (0x00002b6316dd95d7) 10 0x00002b6316dd11f6 main+0x115(argc=<is not available>, argv=0x106f0) [/home/julliard/wine/build/obj-elf64/dlls/d3d8/tests/../../../../wine/include/wine/test.h:624] in d3d8_test (0x00000000000106f0) 11 0x00002b6316dd13fe __wine_spec_exe_entry+0xcd(peb=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in d3d8_test (0x00002b630ed8a908) 12 0x000000007b87217f start_process+0xbe(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1056] in kernel32 (0x00002b6316dd1330) 13 0x00002b630f5e5f7b call_thread_func+0x6a(entry=0x7b8720c0, arg=0x7fffffbef000, frame=0x23f459) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x00007fffafa61d40) 14 0x00002b630f5df856 call_thread_entry_point+0x29() in ntdll (0x00007fffafa61d40) 15 0x00002b630f5b0b66 start_process+0x15(kernel_start=0x23fec8) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x00007fffafa61d40) 16 0x00002b630ea64213 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fffafa61d40) 17 0x00002b630ea64269 wine_switch_to_stack+0x8(func=<is not available>, arg=<is not available>, stack=<is not available>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 18 0x00002b630f5b673e LdrInitializeThunk+0x3dd(kernel_start=0x7b8720c0, unknown2=<is not available>, unknown3=<is not available>, unknown4=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2668] in ntdll (0x00007fffffbef000) 19 0x000000007b8788d2 __wine_kernel_init+0x921() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1257] in kernel32 (0x00007fffafa62fd0) 20 0x00002b630f5b7174 __wine_process_init+0x253() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x00007fffafa6321c) 21 0x00002b630ea621ef wine_init+0x29e(argc=<is not available>, argv=0x7fffafa637a8, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x00007fffafa632b0) 22 0x000000007bf00de1 main+0x70(argc=0x3, argv=0x7fffafa637a8) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:228] in <wine-loader> (0x0000000000000003) 23 0x00002b630efedead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fffafa63798) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 24 0x000000007bf00ca9 _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002b631b0deede getDepthStencilBits+0x2e [/home/julliard/wine/build/obj-elf64/dlls/wined3d/../../../wine/dlls/wined3d/utils.c:2598] in wined3d: movl (%rbx),%edi 2598 switch (format->id) -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2011

Re: Severe startup latencies for Windows applications run under wine

by Henri Verbeet

On 31 August 2011 17:25, Ben Peddell <klightspeed(a)netspace.net.au> wrote: > 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. > I wonder if writing to /proc/pid/mem instead would help here then, similar to what we do in read_process_memory(). Writable /proc/pid/mem is a relatively recent feature though, you'd probably need at least a 2.6.39 kernel.

Aug. 31, 2011

Re: d3dx9_36/tests: Fix printing a NULL string

by Henri Verbeet

On 31 August 2011 17:18, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Looks like the next Coccinelle job will be to flag potential NULL pointers > used in %s in logs, not the tests... > If it's something we get from the application, it should be using the debugstr_*() functions. Wouldn't be a bad thing to check though.

Aug. 31, 2011

Re: d3dx9_36/tests: Fix printing a NULL string

by Michael Stefaniuc

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Bruno Haible was so kind to provide the following test run results: > > glibc SIGSEGV > MacOS X 10.5 (null) > FreeBSD 6.4 (null) > OpenBSD 4.9 (null) > AIX 7.1 empty > HP-UX 11.31 empty > IRIX 6.5 (null) > OSF/1 5.1 (null) > Solaris 10 SIGSEGV > Cygwin (null) > mingw (null) > > for printf("%s", NULL) > > Looks like the next Coccinelle job will be to flag potential NULL pointers > used in %s in logs, not the tests... Not easily done with coccinelle as it doesn't looks into strings; those are just string literal constants for it. Those could be processed in a embedded python rule but the whole logic would need to be implemented there. bye michael

Aug. 31, 2011

Re: [PATCH 2/4] msi: reorder tables to optimize condition evaluation

by Dan Kegel

On Wed, Aug 31, 2011 at 3:10 AM, <buildbot(a)buildbot.kegel.com> wrote: > The Buildbot has detected a failed build on builder runtests while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/136 > BUILD FAILED: failed shell_3 > > > For more info about this message, see http://wiki.winehq.org/BuildBot This breaks loading of wine's gecko here: ../../../tools/runtest -q -P wine -M ieframe.dll -T ../../.. -p ieframe_test.exe.so webbrowser.c && touch webbrowser.ok wine: Unhandled page fault on write access to 0xa06291fc at address 0x407537e9 (thread 002c), starting debugger... Backtrace: =>0 WHERE_execute+0x17a(view=0x11fe58, record=(nil)) [dlls/msi/where.c:821] 1 SELECT_execute+0x9d(view=0x138408, record=(nil)) [dlls/msi/select.c:181] 2 MSI_ViewExecute+0xb4(query=0x11fce0, rec=(nil)) [dlls/msi/msiquery.c:457] 3 get_product_code+0x55(db=0x12e6f0) [dlls/msi/package.c:1393] 4 get_local_package+0x58(filename="Z:\usr\share\wine\gecko\wine_gecko-1.3-x86.msi", localfile="??") [dlls/msi/package.c:1477] 5 MSI_OpenPackageW+0x1f8(szPackage="Z:\usr\share\wine\gecko\wine_gecko-1.3-x86.msi", pPackage=0x33fb14) [dlls/msi/package.c:1546] 6 MsiInstallProductW+0xb3(szPackagePath="Z:\usr\share\wine\gecko\wine_gecko-1.3-x86.msi", szCommandLine=0x0(nil)) [dlls/msi/msi.c:245] 7 install_file+0x24(file_name="Z:\usr\share\wine\gecko\wine_gecko-1.3-x86.msi") [dlls/appwiz.cpl/addons.c:164] 8 install_from_unix_file+0x22b(file_name="/usr/share/wine/gecko/wine_gecko-1.3-x86.msi") [dlls/appwiz.cpl/addons.c:207] 9 install_from_default_dir+0x11f() [dlls/appwiz.cpl/addons.c:276] 10 install_wine_gecko+0x2f() [dlls/appwiz.cpl/addons.c:490] 11 start_params+0x3f(params="install_gecko") [dlls/appwiz.cpl/appwiz.c:978] 12 CPlApplet+0x61(hwndCPL=0x6002e, message=0xa, lParam1=0, lParam2=0x12dbce) [dlls/appwiz.cpl/appwiz.c:1013] 13 Control_DoLaunch+0x524(panel=0x33fd50, hWnd=0x6002e, wszCmd="appwiz.cpl install_gecko") [dlls/shell32/control.c:820] in shell32 (0x0033fd20) 14 Control_RunDLLW+0xde(hWnd=0x6002e, hInst=(nil), cmd="appwiz.cpl install_gecko", nCmdShow=0x5) [dlls/shell32/control.c:846] in shell32 (0x0033fd80) 15 launch+0x35(what="appwiz.cpl install_gecko") [programs/control/control.c:55] 16 wWinMain+0x182(hInst=0x684c0000, hPrev=(nil), lpszCmdLine="appwiz.cpl install_gecko", nCmdShow=0x1) [programs/control/control.c:85] 17 wmain+0x10c(argc=0x3, argv=0x110380) [dlls/winecrt0/exe_wmain.c:50] 0x407537e9 WHERE_execute+0x17a [dlls/msi/where.c:821] in msi: movl %edx,0x0(%eax) 821 tables[i++] = table;

Aug. 31, 2011

Re: Severe startup latencies for Windows applications run under wine

by Ben Peddell

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. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/

Aug. 31, 2011

d3dx9_36/tests: Fix printing a NULL string

by Joerg-Cyril.Hoehle＠t-systems.com

Bruno Haible was so kind to provide the following test run results: glibc SIGSEGV MacOS X 10.5 (null) FreeBSD 6.4 (null) OpenBSD 4.9 (null) AIX 7.1 empty HP-UX 11.31 empty IRIX 6.5 (null) OSF/1 5.1 (null) Solaris 10 SIGSEGV Cygwin (null) mingw (null) for printf("%s", NULL) Looks like the next Coccinelle job will be to flag potential NULL pointers used in %s in logs, not the tests...

Aug. 31, 2011

Re: d3dx9_36/tests: Fix printing a NULL string

by Francois Gouget

On Tue, 30 Aug 2011, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > André Hentschel suggested: > >Should stop the crash on Solaris and maybe others > >- trace("parent_data = (%p) -> %s\n", parent_data, (char *)parent_data); > >+ trace("parent_data (%p) -> %s\n", parent_data, parent_data ? (char *)parent_data : "(null)"); > > This is sooo backwards. You don't want to try and find all places where (null) may be printed. > I remember seeing (null) in logs here and there, so you're telling us that turning on > Wine logs in Solaris can randomly crash Wine because it crashes on printf("%s", NULL)? > > I'm very surprised. I thought Solaris was one of the first machines - decades ago - where I observed "(null)" for NULL. > (Or is that really glibc only?) It appears this was quite extensively debated on the OpenSolaris mailing lists: http://osdir.com/ml/os.solaris.opensolaris.devel/2006-07/msg00026.html That's just to say that no, Solaris (unlike SunOS 4) never allowed a NULL pointer argument to '%s' (not that we should reenact the debate here). One of the recommendations in that thread is to define something like this where needed: #define SAFESTR(s) ((s) ? (s) : "(null)") The Single UNIX Specification does not say what should happen in this case. To me that means we should not depend on '%s' accepting NULL pointers. http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Aug. 31, 2011

Re: hhctrl: IDTB_XXX resource strings

by Owen Rudge

> So I propose the attached patch. I wouldn't object to that. If somebody wants to implement support for the Jump buttons in the future, they can always be re-added, although I would say that in such a circumstance, a resource file entry wouldn't be necessary anyway. -- Owen Rudge http://www.owenrudge.net/

Aug. 31, 2011

Re: hhctrl: IDTB_XXX resource strings

by Francois Gouget

On Mon, 22 Aug 2011, Owen Rudge wrote: [...] > > But from there it's not clear to me they whether they will be used or > > not. Did you specifically mean that only Jump1/2 would not be used or > > does that apply to the other IDTB_XXX strings too? > > I was referring specifically to Jump1/2 in this case. They do get used, > particularly as it looks like we don't currently replace them with the custom > text. Support for Jump 1/2 does not seem to be implemented though (see TB_OnClick()). So they would not do anything which would confuse users. So I propose the attached patch. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Aug. 31, 2011