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

Re: How to find out locking problem

by Henri Verbeet

On 2 January 2011 13:59, <wylda(a)volny.cz> wrote: > err:ntdll:RtlpWaitForCriticalSection section 0x7de77580 > "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, > blocked by 0041, retrying (60 sec) > ... > Backtracing for thread 001c in process 001b (C:\Program Files\2K > Games\BioShock\Builds\Release\Bioshock.exe): > Backtrace: > > =>0 0xb77dc422 __kernel_vsyscall+0xe() in [vdso].so (0x0073f918) > > 1 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x73fafc, > handles=0x73f9fc, flags=0x4, timeout=0x7bc8c082, > signal_object=0x73fa58) > [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x0073fb28) > > 2 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x1, > handles=0x73fbb0, flags=0x4, timeout=(nil), signal_object=0x0(nil)) > [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x0073fb78) > > 3 0x7bc7fcae NtWaitForMultipleObjects+0x73(count=0x1, > handles=0x73fbb0, wait_all=0, alertable=0, timeout=(nil)) > [/build/wine-git_build/dlls/ntdll/sync.c:1162] in ntdll (0x0073fcc8) > > 4 0x7b86e395 WaitForMultipleObjectsEx+0x138(count=0x1, > handles=0x73fd00, wait_all=0, timeout=0xffffffff, alertable=0) > [/build/wine-git_build/dlls/kernel32/sync.c:188] in kernel32 > (0x0073fcf8) > > 5 0x7b86e1c9 WaitForSingleObject+0x3b(handle=0x7f4, > timeout=0xffffffff) [/build/wine-git_build/dlls/kernel32/sync.c:128] > in kernel32 (0x0073fd10) > >From that backtrace, it doesn't look like 001c is waiting for a critical section at all.

Jan. 2, 2011

Re: wined3d: Update detection of vertex blend capabilities

by Henri Verbeet

On 2 January 2011 10:52, Jeremy Chin <rekless(a)fastmail.fm> wrote: > Newer video cards have stopped reporting the ARB_VERTEX_BLEND GL capability, > but ARB_VERTEX_PROGRAM implies the same capability. > I don't think so. If this works at all it's probably because you're passing some previous value of gl_max (like GL_MAX_TEXTURE_UNITS_ARB) for the number of blend matrices.

Jan. 2, 2011

How to find out locking problem

by wylda＠volny.cz

> ...get the stacks of all running processes with the command > > bt all > > With luck, you can then see which two code paths are > competing for the lock. Thanks for tip! Are the following traces from problematic threads useful or will i have to post all the thread traces? (Just repeat: happens in case of load/save of savegame): fixme:thread:SetThreadIdealProcessor (0x764): stub err:ntdll:RtlpWaitForCriticalSection section 0x7de77580 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, blocked by 0041, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x41f24e4 "?" wait timed out in thread 0045, blocked by 0044, retrying (60 sec) Selected/affected threads from "bt all": ======================================== Backtracing for thread 001c in process 001b (C:\Program Files\2K Games\BioShock\Builds\Release\Bioshock.exe): Backtrace: =>0 0xb77dc422 __kernel_vsyscall+0xe() in [vdso].so (0x0073f918) 1 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x73fafc, handles=0x73f9fc, flags=0x4, timeout=0x7bc8c082, signal_object=0x73fa58) [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x0073fb28) 2 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x1, handles=0x73fbb0, flags=0x4, timeout=(nil), signal_object=0x0(nil)) [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x0073fb78) 3 0x7bc7fcae NtWaitForMultipleObjects+0x73(count=0x1, handles=0x73fbb0, wait_all=0, alertable=0, timeout=(nil)) [/build/wine-git_build/dlls/ntdll/sync.c:1162] in ntdll (0x0073fcc8) 4 0x7b86e395 WaitForMultipleObjectsEx+0x138(count=0x1, handles=0x73fd00, wait_all=0, timeout=0xffffffff, alertable=0) [/build/wine-git_build/dlls/kernel32/sync.c:188] in kernel32 (0x0073fcf8) 5 0x7b86e1c9 WaitForSingleObject+0x3b(handle=0x7f4, timeout=0xffffffff) [/build/wine-git_build/dlls/kernel32/sync.c:128] in kernel32 (0x0073fd10) 6 0x1145ffd1 in bioshock (+0xb5ffd0) (0x0073fd44) 7 0x1171bac7 in bioshock (+0xe1bac6) (0x0073fd7c) 8 0x1171bc3d in bioshock (+0xe1bc3c) (0x0073fe60) 9 0x7b85d54c call_process_entry+0xb() in kernel32 (0x0073fe78) 10 0x7b85d54c call_process_entry+0xb() in kernel32 (0x0073fec8) 11 0x7b85d692 start_process+0x143(peb=0x7ffdf000) [/build/wine-git_build/dlls/kernel32/process.c:1086] in kernel32 (0x0073fed8) 12 0x7bc7be90 call_thread_func+0xb() in ntdll (0x0073ffb8) 13 0x7bc7bece call_thread_entry_point+0x33(entry=0x7b85d54e, arg=0x7ffdf000) [/build/wine-git_build/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0073ffe8) 14 0x7bc53fdc start_process+0x2f(kernel_start=0x7b85d54e) [/build/wine-git_build/dlls/ntdll/loader.c:2606] in ntdll (0x00000000) Backtracing for thread 0041 in process 001b (C:\Program Files\2K Games\BioShock\Builds\Release\Bioshock.exe): Backtrace: =>0 0xb77dc422 __kernel_vsyscall+0xe() in [vdso].so (0x1283de88) 1 0x7d847231 in libgl.so.1 (+0x7b230) (0x1283df58) 2 0x7e4314fa context_apply_fbo_entry+0x29(context=0x121ba5b8, target=0x8d40, entry=0x182e98) [/build/wine-git_build/dlls/wined3d/context.c:440] in wined3d (0x1283df98) 3 0x7e4314fa context_apply_fbo_entry+0x29(context=0x121ba5b8, target=0x8d40, entry=0x182e80) [/build/wine-git_build/dlls/wined3d/context.c:440] in wined3d (0x1283dfd8) 4 0x7e431703 context_apply_fbo_state+0xd5(context=0x121ba5b8, target=0x8d40, render_targets=0x14113658, depth_stencil=0x1a13a8, location=0x40) [/build/wine-git_build/dlls/wined3d/context.c:492] in wined3d (0x1283e038) 5 0x7e43b83c context_apply_clear_state+0xec(context=0x121ba5b8, device=0x18a008, rt_count=0x8, rts=0x182b80, depth_stencil=0x1a13a8) [/build/wine-git_build/dlls/wined3d/context.c:2148] in wined3d (0x1283e178) 6 0x7e440306 device_clear_render_targets+0x1a2(device=0x18a008, rt_count=0x8, rts=0x182b80, rect_count=0, rects=(nil), draw_rect=0x1283e1cc, flags=0x7, color=0x1283e1dc, depth=1.000000, stencil=0) [/build/wine-git_build/dlls/wined3d/device.c:689] in wined3d (0x1283e208) 7 0x7e4512fa IWineD3DDeviceImpl_Clear+0x1ef(iface=0x18a008, rect_count=0, rects=(nil), flags=0x7, color=0, depth=1.000000, stencil=0) [/build/wine-git_build/dlls/wined3d/device.c:4744] in wined3d (0x1283e258) 8 0x7e5743c1 IDirect3DDevice9Impl_Clear+0xda(iface=0x181f90, Count=0, pRects=(nil), Flags=0x7, Color=0, Z=1.000000, Stencil=0) [/build/wine-git_build/dlls/d3d9/device.c:1273] in d3d9 (0x1283e2a0) 9 0x10b8f39d in bioshock (+0x28f39c) (0x1283e324) 10 0x10ae934e in bioshock (+0x1e934d) (0x1c268008) 11 0x00000003 (0x11015464) 12 0x10aff710 in bioshock (+0x1ff70f) (0x10a578a0) 13 0x0001088e (0x8df18b56) 14 0x00000000 (0x00000000) Backtracing for thread 0045 in process 001b (C:\Program Files\2K Games\BioShock\Builds\Release\Bioshock.exe): Backtrace: =>0 0xb77dc424 __kernel_vsyscall+0x10() in [vdso].so (0x00000000) Backtracing for thread 0044 in process 001b (C:\Program Files\2K Games\BioShock\Builds\Release\Bioshock.exe): Backtrace: =>0 0xb77dc422 __kernel_vsyscall+0xe() in [vdso].so (0x7f4fe5fc) 1 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x7f4fe7e0, handles=0x7f4fe6e0, flags=0x4, timeout=0x7bc768d2, signal_object=0x7bcb15a0) [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x7f4fe80c) 2 0x7bc7fbbe NTDLL_wait_for_multiple_objects+0x1f0(count=0x1, handles=0x7f4fe894, flags=0x4, timeout=(nil), signal_object=0x0(nil)) [/build/wine-git_build/dlls/ntdll/sync.c:1124] in ntdll (0x7f4fe85c) 3 0x7bc7fcae NtWaitForMultipleObjects+0x73(count=0x1, handles=0x7f4fe894, wait_all=0, alertable=0, timeout=(nil)) [/build/wine-git_build/dlls/ntdll/sync.c:1162] in ntdll (0x7f4fe9ac) 4 0x7b86e395 WaitForMultipleObjectsEx+0x138(count=0x1, handles=0x7f4fe9e4, wait_all=0, timeout=0xffffffff, alertable=0) [/build/wine-git_build/dlls/kernel32/sync.c:188] in kernel32 (0x7f4fe9dc) 5 0x7b86e1c9 WaitForSingleObject+0x3b(handle=0x6f0, timeout=0xffffffff) [/build/wine-git_build/dlls/kernel32/sync.c:128] in kernel32 (0x00000000)

Jan. 2, 2011

RFC: include: Add '_ONCE' variants of DPRINTF, FIXME, WARN and ERR

by Sven Baars

Hey all, adding '_ONCE' variants of DPRINTF, FIXME, WARN and ERR is a topic that came up before on wine devel. The first version of the attached patch was submitted by Max TenEyck Woodbury, but was deferred until after wine 1.2. I still thought it was a good idea to have the _ONCE variants, so I mailed Max, but he said he backed out after finding out it was not feasible to do it right. I fixed some errors in his patch, but as Max pointed out to me, for compilers that don't support variadic macros, it's not possible to create a scope block to declare the static variable in. This is because of the (void)wine_dbg_printf call at the end of the (non-variadic) __WINE_DPRINTF_ONCE macro. wine_dbg_printf is a variadic function, any code after that function call breaks the macro (so a ';}while(0)' can't be added to close the scope). AFAIK, this is the reason why a do{...}while(0) loop can't be used as it's done in the others. Now I was wondering if there is a solution to this, or if it's ok to implement the _ONCE variants with the current patch. Using the current patch would mean that with a compiler that doesn't support C99, you would still have you at lot of the FIXMEs/WARNs where you don't want them. This would not be a problem right after the implementation, but only after replacing constructions like static int once; if(!once++) FIXME() with the corresponding _ONCE(). It wouldn't really break anything though. Also, it'd probably be better to replace #elif defined(__SUNPRO_C) with something like #elif __STDC_VERSION__ >= 199901L because that's what you're actually looking for. This would mean that the non-variadic _ONCE implementation is less of a problem, because more compilers would use the variadic __WINE_DPRINTF_ONCE macro. The #ifdef __GNUC__ would still remain because of their own implementation of variadic macros (from before C99). Have a happy new year! Sven --- include/wine/debug.h | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 43 insertions(+), 1 deletions(-)

Jan. 2, 2011

Re: How to find out locking problem

by James McKenzie

On 1/1/11 7:10 PM, Dan Kegel wrote: > Sometimes it helps to run winedbg from another window > and get the stacks of all running processes with the command > bt all > With luck, you can then see which two code paths are > competing for the lock. > Dan: I've also been getting random 'locks' and this is only running 'make test' and that resulted in an update to the Wine Configuration. This looks like a regression of the problem that was fixed a long time ago, where interprocess locking happened constantly. Maybe Wylda can find it, if the problem is constant on his system. James McKenzie

Jan. 2, 2011

re: How to find out locking problem

by Dan Kegel

Sometimes it helps to run winedbg from another window and get the stacks of all running processes with the command bt all With luck, you can then see which two code paths are competing for the lock.

Jan. 2, 2011

How to find out locking problem

by wylda＠volny.cz

Happy New Year! i notice, that since 1.3 i get quite offten locking issue. It looks like, that last OK version was 1.2-rc7. This problem happens in Bioshock on load/save, but i noticed that other users have same problem with games on the same game engine. Could someone help me, what should i do in this lockin-case as first, please? Thanks in advance! Regards W. ... fixme:thread:SetThreadIdealProcessor (0x734): stub err:ntdll:RtlpWaitForCriticalSection section 0x7deac200 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001a, blocked by 0041, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x5486584 "?" wait timed out in thread 0045, blocked by 0044, retrying (60 sec)

Jan. 1, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os

by James McKenzie

On 1/1/11 4:07 AM, maury loïc wrote: > On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie > <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: > > On 12/31/10 1:50 PM, Charles Davis wrote: > > On 12/31/10 1:11 PM, Ken Thomases wrote: > > I should add that this patch seem correct to me. It > couldn't hurt to get Charles Davis's input, of course. > > I agree, for now. He should at least put a comment in to the > effect of > "if we got this far, there's already media in the drive." > > That was the point I was trying to get to. Based on Ken's comment > below, the device is temporary and only exists for the time period > that the device is in use. > > MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is > to check if the media has changed. The Linux and FreeBSD > implementations basically just check if there's media in > the drive. On Mac OS X, the BSD device file just plain > doesn't exist unless and until there's media mounted. > There's no permanent BSD device file for the drive > itself. So, if CDROM_Verify() is called, which requires > that the BSD device file is opened and thus is present, > that by itself implies that there's media in the drive. > Therefore, CDROM_Verify() should just return success. > > Makes sense. But the 'right' way to implement this on Mac OS > is to ask > DiskArbitration to tell us when the media changes. (In fact, > the right > way to implement this elsewhere is to ask udev or hald the > same thing.) > Then we can return STATUS_VERIFY_REQUIRED (as documented) when > the media > actually has changed. For now, though, Loïc's patch is OK. > > Is this going to be changed sometime in the future to work per the > documentation? > > AJ wants to eventually move some (all?) of the disk/CD/DVD/storage > IOCTLs into mountmgr anyway, where Wine's fake storage drivers are > hosted. Mountmgr already has infrastructure in place to talk > to DA on > Mac OS and to hald on Linux/FreeBSD, so doing this the 'right' > way will > be much easier there. > > This is a good point. Maybe the effort should be to move the code > over to mountmgr.sys rather than implement and have to move it later. > > And I am aware what the process is, I was asking general questions > based on what the comments were in the patch. Basically, the > comments did not make sense to me and I was asking for > clarification. That was provided by both Ken and Charles' comments. > > James McKenzie > > > > > Hello Mr.McKenzie and Wine community, > > Happy new years. > > In fact, I don't try to resolve the SCSI command ioctl, to support the > cd-rom, > I have just modified the CDROM_Verify(), because I thought, this function > verify if the media is present in the device. > > Here my reasoning : > > in dll/ntdll/cdrom.c, we are in the function CDROM_DeviceIoControl(). > > get_parent_device() is called to get the device and Wine try to open > the device. > > For what I understood, Mac Os will create an entry object into the > I/O Registry, > who represent our device, (the device exist at boot time or when it is > plugged). > > get_parent_device() will find the object, and store the name of device. > > After the device is found, Wine try to open it. > > In the case of IOCTL_*_CHECK_VERIFY request, CDROM_Verify is called, > In this function, we already know we have a valid device, > in use, but if the device is present, the media is present too, we can > not have a file descriptor to a device, without > media present. > > Thank you for the explanation of why you did it this way. This does work. MacOSX has to be different in how it does this and that makes things difficult for Mac users and developers (when you step outside the 'box' that Apple defined for us.) James McKenzie

Jan. 1, 2011

Re: happy new year!

by James McKenzie

On 12/31/10 10:43 PM, Dan Kegel wrote: > May all your tests be green, and all your patches pass peer review :-) > > > And may Quality Assurance Testing pass all of your code the first time and say "Good Job". James McKenzie

Jan. 1, 2011

Re: comctl32/tests: Add test for horizontal spacing to test_hittest.

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=8018 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2KPROSP4 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === WXPPROSP3 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2K3R2SESP2 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === WVISTAADM (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2K8SE (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PRO (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PROX64 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PROX64 (64 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96)

Jan. 1, 2011