April 2008 - Wine-bugs - list.winehq.org

[Bug 9798] New: bioshock demo needs glsl enabled
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=9798 Summary: bioshock demo needs glsl enabled Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8240) --> (http://bugs.winehq.org/attachment.cgi?id=8240) crash log with glsl disabled Hello, Bioshock demo crashes if glsl is not enabled. Attached are relevant traces made with: WINEDEBUG=+seh,+tid,+d3d,+d3d_shader wine ./Bioshock.exe -dx9 Using following registry settings enables bioshock demo to run: --- snip --- HKEY_CURRENT_USER/Software/Wine/Direct3D UseGLSL = "enabled" --- snip --- Optional: OffscreenRenderingMode = "fbo" ================== Addendum: wine --version wine-0.9.45-406-g2ba3247 Currently uses secuROM hack (http://bugs.winehq.org/attachment.cgi?id=8235 ) to run, see http://bugs.winehq.org/show_bug.cgi?id=7065 Be sure to include "-dx9" command line to work around directx 10 issue. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10225] New: SafeDisc 2. x triggers async device ioctl status code propagation bug in wine server
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10225 Summary: SafeDisc 2.x triggers async device ioctl status code propagation bug in wine server Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8843) --> (http://bugs.winehq.org/attachment.cgi?id=8843) relevant trace which shows ioctl status code propagation bug Hello, while testing my proof-of-concept patch which makes SafeDisc v2 (yuck!) finally work, I stumbled across a nasty ioctl status code propagation (completion) bug in wine server. Wasted several hours on it .. I was suspecting SD issue whole time, but its a wine server bug :( Attached is relevant trace (WINEDEBUG=+seh,+tid,+relay,+ntoskrnl,+server wine ./BfVietnam.exe) Before the bug is triggered, the SafeDisc security driver makes several device ioctl requests which return 0xC0000001 (unsuccessful) on purpose, e.g. reading debug Drx registers with index that does not exist. This is intended to fool reversers :-) The next operation - checking IDT entries should succeed - but does not (as seen from calling client). The kernel driver completes the operation successfully and returns irp.IoStatus.u.Status == 0 with xxxx bytes in output buffer. I verified it several times by debugging the kernel driver. Upon driver ioctl call return, get_next_device_request() is triggered again in ntoskrnl event loop which sets the return data (and status code) -> set_ioctl_result(). This queues an APC, waking up the client (alertable state). The client process device ioctl completes with 0 (FALSE) which is wrong. Further debugging showed that ioctl_completion APC (dlls/ntdll/file.c) returns the errornous status code in get_ioctl_result() when woken up by server. This error is then propagated in server_ioctl_file() to result in wrong NtDeviceIoControlFile() return code. What puzzled me is that "ioctl->status" is correctly set by set_ioctl_result() (=0) but get_ioctl_result() - called within client context - yields the previous error code (0xC0000001 of failed request). This is either a problem of global vs. thread local error status (global_error vs. current->error/thread) or the ioctl call data is the wrong one. The following patch works for me, letting SD 2.x continue - though i'm not sure if it's right: --- snip --- diff --git a/server/device.c b/server/device.c index 46b2796..8fe8f7c 100644 --- a/server/device.c +++ b/server/device.c @@ -528,7 +528,7 @@ DECL_HANDLER(get_ioctl_result) ioctl->out_data = NULL; } } - set_error( ioctl->status ); + list_remove( &ioctl->dev_entry ); release_object( ioctl ); /* no longer on the device queue */ } --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 10293] New: sequentially running games/ apps with different SafeDisc versions fails
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10293 Summary: sequentially running games/apps with different SafeDisc versions fails Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8945) --> (http://bugs.winehq.org/attachment.cgi?id=8945) Patch which fixes various isses regarding kmode driver unload/reload Hello, currently wine's kernel mode driver cleanup/unloading facility has several issues when it comes to applications/games that unload and reload different driver versions on the fly. Example: run multiple SafeDisc 2.x, 3.x and 4.x games sequentially. Symptoms: game either hangs/crashes/exits silently Usually the SD security driver is placed in "c:\windows\system32\drivers\secdrv.sys" If a SafeDisc protected program encounters a driver version that is incompatible it does the following: - stop the current security service (should unload the driver) - unpack own security driver from resources to temp storage and move the binary to "c:\windows\system32\drivers\secdrv.sys", overwriting the previous - restart the service (loads the new driver) This currently fails for various reasons: (1) The driver binary is loaded using LoadLibrary() -> the matching FreeLibrary() is missing on service stop. This leads to sharing violation when the driver binary going to be replaced (CopyFile fails). (2) No driver unload routine called. Very problematic. Various objects (symlinks) created by driver entry are not freed. When the driver is reloaded the init routine usually fails with "object exists". (3) Driver state objects (driver_obj, driver_extension) have undefined state due to static storage. Raises all sorts of problems because the driver entry routine does not init all fields. --------- Attached is a patch which fixes these problems, allowing to sequentially run programs with different SafeDisc Versions. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10

[Bug 10451] New: Various AutoDesk 2008 product installers fail due to unimplemented msi. MsiEnumComponentCostsW
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10451 Summary: Various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9156) --> (http://bugs.winehq.org/attachment.cgi?id=9156) stub impl of msi.MsiEnumComponentCostsW to keep AutoDesk 2008 installers happy Hello, various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW API (mentioned in bug 9809). --- snip --- wine: Call from 0x7b841460 to unimplemented function msi.dll.MsiEnumComponentCostsW, aborting wine: Unimplemented function msi.dll.MsiEnumComponentCostsW called at address 0x7b841460 (thread 000e), starting debugger... Unhandled exception: unimplemented function msi.dll.MsiEnumComponentCostsW called in 32-bit code (0x7b8414d8). --- snip --- Attached patch makes installer happy. Though that API (A/W) should be fleshed out some day ... this is left as exercise for msi maintainers :-) If you test this on AutoDesk 2008 installers, you need my shell32/shlfileop patch from bug 9809 too. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10478] New: wine server get/set thread context doesn' t work correctly if simultaneously used by debugger and debuggee
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10478 Summary: wine server get/set thread context doesn't work correctly if simultaneously used by debugger and debuggee Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-debug AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9209) --> (http://bugs.winehq.org/attachment.cgi?id=9209) WINEDEBUG=+tid,+server,+win trace of debugging session Hello, while debugging a target with some debugger I experienced severe problems with wine server get/set thread context implementation. It doesn't work correctly if the get/set thread context API is simultaneously used by both, the debugger and the debuggee to manage exception events/control execution transfer. Attached is WINEDEBUG=+tid,+seh,+win trace (don't bother with +win channel output, was for my own purpose). pid=0008, tid=0009 debugger main thread pid=0008, tid=000d debugger debug event loop thread pid=000e, tid=000f debuggee main thread pid=000e, tid=0010 debuggee child thread pid=000e, tid=0011 debuggee child thread pid=000e, tid=0012 debuggee child thread Search for "000d: get_thread_context() = ACCESS_DENIED { self=0, context={} }" in attached log and walk your way back... --- snip --- 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4}} ) 000d: *wakeup* signaled=0 cookie=0x616e24c0 0010: *sent signal* signal=10 0011: *sent signal* signal=10 0012: *sent signal* signal=10 000f: queue_exception_event() = 0 { handle=0x244 } --- snip --- Debuggee main thread throws first chance C++ exception (queues event). Ok. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves (on purpose!). Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exception,{code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4},first=1} } .. 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34dfd4 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 000d: continue_debug_event() = 0 .. --- snip --- Debugger wakes up and sees first chance C++ exception, decides to pass it to debuggee (resumes execution of threads). Ok. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}} } 0010: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0010: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} } 0011: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0011: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} } 000d: select( flags=4, cookie=0x616e24c0, signal=(nil), prev_apc=(nil), timeout=+1.0000000, result={}, handles={0xa8} ) 000d: select() = PENDING { apc_handle=(nil), timeout=1c828ffa61af642 (+1.0000000), call={APC_NONE} } 0012: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0012: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} } 000f: get_process_info( handle=0xffffffff ) 000f: get_process_info() = 0 { pid=000e, ppid=0008, exit_code=259, priority=2, affinity=1, peb=0x7ffdf000, start_time=1c828ff9f2037c6 (-10.7374150), end_time=0 } 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=02d410d8,dr2=a3f67060,dr3=00000000,dr6=00110000,dr7=00000002,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}},rec={code=e0434f4d,flags=1,rec=(nil),addr=0x7b841300,params={80004002}} ) --- snip --- Main debuggee thread SEH evaluates first chance exception and converts it internally to CLR exception, throwing again. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves again (on purpose!). Ok. --- snip --- 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000f: *signal* signal=19 000d: get_thread_context() = 0 { self=0, context={flags=0001003f,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}} } 000d: read_process_memory( handle=0xb8, addr=0x7b841378 ) 000f: *signal* signal=19 000d: read_process_memory() = 0 { data={8b} } 000d: resume_thread( handle=0xbc ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd4 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd8 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xf8 ) 000d: resume_thread() = 0 { count=1 } 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34e824 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 0012: *wakeup* signaled=258 cookie=0x7ffcf7b4 000d: continue_debug_event() = 0 --- snip --- Debugger wakes up again, now seeing the CLR exception. Debugger suspends debuggee threads - although unnecessary due to debugging event before = already suspended. This exception type is unhandled, main debuggee thread receives SIGSTOP. Execution of debuggee threads resumed. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1= .. 000f: *killed* exit_code=0 --- snip --- Debuggee main thread dies. Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exit_thread,code=0} } 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: read_process_memory( handle=0xb8, addr=(nil) ) 000d: read_process_memory() = ACCESS_DENIED { data={} } .. --- snip --- Debugger wakes up, sees debuggee (main) thread termination event. Suspends remaining debuggee threads - although unnecessary due to debugging event before = already suspended. Now the problem: the debugger can't get the thread context of any debuggee threads nor process memory anymore after this point. Basically dead end here... The reason is the way server/thread.c/get_thread_context() and server/thread.c/set_thread_context() handles thread->context and thread->suspend_context data ("self" vs. "foreign" threads) child threads "self": set_thread_context() -> suspend == 1 -> thread->suspend_context filled get_thread_context(): req->suspend == 1 && thread == current && thread->suspend_context --- snip --- if (thread->context == thread->suspend_context) thread->context = NULL; set_reply_data_ptr( thread->suspend_context, sizeof(CONTEXT) ); thread->suspend_context = NULL; --- snip --- Which resets the context and suspend context data. Next time when the debugger itself tries to query the thread context of already suspended debuggee child threads it will obviously fail: "foreign" debugger thread: get_thread_context() -> suspend == 0 --- snip --- else if (thread != current && !thread->context) { /* thread is not suspended, retry (if it's still running) */ if (thread->state != RUNNING) set_error( STATUS_ACCESS_DENIED ); else set_error( STATUS_PENDING ); } --- snip --- I guess this is an oversight, a behavior not really intended? Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 11789] New: Recent Fls API additions break many installers/apps
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11789 Summary: Recent Fls API additions break many installers/apps Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after upgrading to recent GIT (wine-0.9.56-264-g848383a) it seems the recent Fls API additions broke almost every installer i'm working on ;-( http://source.winehq.org/git/wine.git/?a=commit;h=6d6e9a42b13c827d1cc795c3b… http://source.winehq.org/git/wine.git/?a=commit;h=b2ad268a8b7d7ac65029bbdd7… I won't question if there was a specific need to introduce this ... Reason of crash in FlsAlloc() is simple. Different TEB definition in <thread.h> vs. <winternl.h> leads to incorrect TEB allocation size (ntdll -> thread.h) vs. usage (fiber/Fls -> winternl.h) Solution: use winternl.h TEB definition to ensure correct TEB allocation size in dlls/ntdll/thread.c Either change include order of both (needs <stdarg.h>) .. or sync both .. or better get rid of the thread.h one to avoid such recurring problem. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 9454] New: Panzer General III Scorched Earth hang with seh: setup_exception nested exception
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=9454 Summary: Panzer General III Scorched Earth hang with seh:setup_exception nested exception Product: Wine Version: 0.9.44. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: phajdan.jr(a)gmail.com While normally playing in the battle screen, the game hanged, the music started to repeat a short fragment, and the UI was unresponsive. The error printed was err:seh:setup_exception nested exception on signal stack in thread 002b eip ffffe405 esp 7ffdd648 stack 0x241000-0x350000 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 12

[Bug 9400] New: Panzerg General III Scorched Earth random hang, threading-related
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=9400 Summary: Panzerg General III Scorched Earth random hang, threading-related Product: Wine Version: 0.9.43. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: phajdan.jr(a)gmail.com At random moments the game hangs, will attach wine output in a moment. Note that this log is only relevant for wine 0.9.43. Before it also hanged sometimes, but the message err:ntdll:RtlpWaitForCriticalSection section 0x7eb87ae0 "gdiobj.c: GDI_level" wait timed out in thread 000c, blocked by 0009, retrying (60 sec) wine: Critical section 7eb87ae0 wait failed at address 0x7ef97b20 (thread 000c), starting debugger... was not present. And before upgrade to 0.9.43 it had some problems with music, like randomly switching tracks etc (sometimes it hanged during these, sometimes not). After the upgrade the problem is gone, when it hangs music still plays, but the mouse does not move, and the game does not receive keyboard input. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 14

[Bug 11621] New: putty.exe in telnet mode don't display anything
by wine-bugs＠winehq.org 09 Oct '11

09 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11621 Summary: putty.exe in telnet mode don't display anything Product: Wine Version: 0.9.55. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fhorse(a)libero.it The windows ssh/telnet application putty.exe works well in ssh mode, but in telnet mode does not display anything on the screen. I'have sniffed tcp packets and I noticed that the telnet communication works well, make login, run commands, but does not appear anything. Sorry for my english. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 35

[Bug 12813] New: XMLSpy 2007 refuses to install
by wine-bugs＠winehq.org 09 Oct '11

09 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=12813 Summary: XMLSpy 2007 refuses to install Product: Wine Version: 0.9.60 Platform: PC URL: http://www.brothersoft.com/altova-xmlspy-enterprise- edition-2007-60072.html OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=12495) --> (http://bugs.winehq.org/attachment.cgi?id=12495) +msi,+msidb log in git, tailed to 500000, bzip2 -9'ed While checking on bug 9053, it appears XMLSpy will not install. Probably a regression, but I can't be sure, I'll try to check later. err:msi:msi_view_get_row Invalid type! Looks a bit suspicious, so setting to msi for now. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 9