September 2011 - Wine-Bugs - list.winehq.org

[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 Oct. 12, 2011

Oct. 12, 2011

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 Oct. 12, 2011

Oct. 12, 2011

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 14499] New: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14499 Summary: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a quickie, as title says. Section header param passed to ImageDirectoryEntryToDataEx is [out, optional]. Crashes RtlImageRvaToVa if caller doesn't initialize the out param to zero (stack var). --- snip --- .. 0020:Call dbghelp.ImageDirectoryEntryToDataEx(00340000,00000000,00000006,0032cc34,0032cc38) ret=004048ec 0020:Call ntdll.RtlImageNtHeader(00340000) ret=6076ce7b 0020:Ret ntdll.RtlImageNtHeader() retval=003400e8 ret=6076ce7b 0020:Call ntdll.RtlImageRvaToVa(003400e8,00340000,00001270,0032cc38) ret=6076ceeb 0020:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc4337a --- snip --- Fix: unconditionally "if (section) *section = NULL" on ImageDirectoryEntryToDataEx entry (like size). 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 14539] New: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14539 Summary: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a regression in RtlIsTextUnicode causes VS.NET 2005 Installer and probably others to fail. The setup database, a unicode .ini file is not correctly identified as such. --- snip --- 0026:Call setupapi.SetupOpenInfFileW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000002,0033eab4) ret=5022237f 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000000,00000000) ret=606148a8 0026:Ret KERNEL32.GetFullPathNameW() retval=00000016 ret=606148a8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,0000002c) ret=606148e0 0026:Ret ntdll.RtlAllocateHeap() retval=00142a08 ret=606148e0 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000016,00142a08,00000000) ret=60614909 0026:Ret KERNEL32.GetFullPathNameW() retval=00000015 ret=60614909 0026:Call KERNEL32.CreateFileW(00142a08 L"E:\\vs\\setup\\setup.sdb",80000000,00000001,00000000,00000003,00000000,00000000) ret=60614947 0026:Ret KERNEL32.CreateFileW() retval=00000068 ret=60614947 0026:Call KERNEL32.GetFileSize(00000068,00000000) ret=60614966 0026:Ret KERNEL32.GetFileSize() retval=00012f9e ret=60614966 0026:Call KERNEL32.CreateFileMappingW(00000068,00000000,00000002,00000000,00012f9e,00000000) ret=6061499b 0026:Ret KERNEL32.CreateFileMappingW() retval=0000006c ret=6061499b 0026:Call KERNEL32.MapViewOfFile(0000006c,00000004,00000000,00000000,00012f9e) ret=60614a2f 0026:Ret KERNEL32.MapViewOfFile() retval=003b0000 ret=60614a2f 0026:Call ntdll.NtClose(0000006c) ret=60614a3d 0026:Ret ntdll.NtClose() retval=00000000 ret=60614a3d 0026:Call ntdll.RtlAllocateHeap(00110000,00000008,0000002c) ret=60614a80 0026:Ret ntdll.RtlAllocateHeap() retval=00142a40 ret=60614a80 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614ab3 0026:Ret ntdll.RtlAllocateHeap() retval=00147ab8 ret=60614ab3 0026:Call ntdll.RtlIsTextUnicode(003b0000,00012f9e,00000000) ret=60614ae8 0026:Ret ntdll.RtlIsTextUnicode() retval=00000000 ret=60614ae8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614b2b 0026:Ret ntdll.RtlAllocateHeap() retval=0016da00 ret=60614b2b 0026:Call KERNEL32.MultiByteToWideChar(00000000,00000000,003b0000 "\xff\xfe\r",00012f9e,0016da00,00012f9e) ret=60614b6f 0026:Ret KERNEL32.MultiByteToWideChar() retval=00012f9e ret=60614b6f 0026:Call ntdll.RtlReAllocateHeap(00110000,00000010,00147ab8,00000000) ret=606145d9 0026:Ret ntdll.RtlReAllocateHeap() retval=00147ab8 ret=606145d9 0026:Call ntdll.RtlFreeHeap(00110000,00000000,0016da00) ret=60614ba9 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614ba9 0026:Call KERNEL32.UnmapViewOfFile(003b0000) ret=60614bc2 0026:Ret KERNEL32.UnmapViewOfFile() retval=00000001 ret=60614bc2 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a40) ret=60614be5 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614be5 0026:Call KERNEL32.CloseHandle(00000068) ret=606149af 0026:Ret KERNEL32.CloseHandle() retval=00000001 ret=606149af 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a08) ret=606149d2 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=606149d2 0026:Ret setupapi.SetupOpenInfFileW() retval=ffffffff ret=5022237f .. 0026:Call KERNEL32.WritePrivateProfileStringW(501b82fc L"Error",0033ed28 L"Error1",007ebbe8 L"0:0:setup.exe:LoadSetupDatabase() : The .sdb file is either missing, corrupt, or the signiture portion is missing",0033eb14 L"C:\\windows\\temp\\msinterr.txt") ret=501fcdeb --- snip --- The input data for your pleasure: --- snip --- $ hexdump -n 256 -C setup.sdb 00000000 ff fe 0d 00 0a 00 5b 00 56 00 65 00 72 00 73 00 |......[.V.e.r.s.| 00000010 69 00 6f 00 6e 00 5d 00 0d 00 0a 00 53 00 69 00 |i.o.n.].....S.i.| 00000020 67 00 6e 00 61 00 74 00 75 00 72 00 65 00 20 00 |g.n.a.t.u.r.e. .| 00000030 3d 00 20 00 22 00 24 00 57 00 69 00 6e 00 64 00 |=. .".$.W.i.n.d.| 00000040 6f 00 77 00 73 00 20 00 4e 00 54 00 24 00 22 00 |o.w.s. .N.T.$.".| 00000050 0d 00 0a 00 50 00 72 00 6f 00 76 00 69 00 64 00 |....P.r.o.v.i.d.| 00000060 65 00 72 00 3d 00 22 00 4d 00 69 00 63 00 72 00 |e.r.=.".M.i.c.r.| 00000070 6f 00 73 00 6f 00 66 00 74 00 20 00 56 00 69 00 |o.s.o.f.t. .V.i.| 00000080 73 00 75 00 61 00 6c 00 20 00 53 00 74 00 75 00 |s.u.a.l. .S.t.u.| 00000090 64 00 69 00 6f 00 20 00 32 00 30 00 30 00 35 00 |d.i.o. .2.0.0.5.| 000000a0 20 00 50 00 72 00 6f 00 66 00 65 00 73 00 73 00 | .P.r.o.f.e.s.s.| 000000b0 69 00 6f 00 6e 00 61 00 6c 00 20 00 45 00 64 00 |i.o.n.a.l. .E.d.| 000000c0 69 00 74 00 69 00 6f 00 6e 00 20 00 2d 00 20 00 |i.t.i.o.n. .-. .| 000000d0 45 00 4e 00 55 00 22 00 0d 00 0a 00 56 00 65 00 |E.N.U.".....V.e.| 000000e0 72 00 73 00 69 00 6f 00 6e 00 3d 00 38 00 30 00 |r.s.i.o.n.=.8.0.| 000000f0 30 00 2e 00 31 00 30 00 30 00 2e 00 30 00 30 00 |0...1.0.0...0.0.| --- snip --- BOM for UTF-16 is there. The problem is the ideographic space (U+3000) in reverse control chars check (punctuation symbol or whitespace in languages like Chinese, Japanese, or Korean). --- snip --- static const WCHAR byterev_control_chars[] = {0x0d00,0x0a00,0x0900,0x2000,0x0030,0}; --- snip --- This clashes with the multibyte mapping of digit 0: 0x30 -> 0x0030 By removing the reversed ideographic space, the file is correctly recognized. Problematic commit: 8f3ae2011c39d092b0c8e2e6a9aabddbd2596748 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 5

[Bug 14568] New: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14568 Summary: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, ole32.CoGetContextToken being currently a stub prints out large amounts of FIXME's when .NET runtime queries COM+ context for run/debugged .NET applications. --- snip --- .. fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub .. <repeat this gazillion times> --- snip --- Please use a static or remove the FIXME. It's really annoying and makes console tracing/debugging of .NET apps really messy. And no, WINEDEBUG=-ole is *not* an option, it actually hides other bugs. 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 16544] New: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=16544 Summary: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid Product: Wine Version: 1.1.10 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while revisiting a Battlefield 2 issue I came across another one... BF2 voice setup (C:\Program Files\EA GAMES\Battlefield 2\BF2VoiceSetup.exe) crashes when "Save Settings" button is clicked. This happens from BF2 sub-installer (causing no harm) or when the voice setup app is run stand alone. --- snip --- .. wine: Unhandled page fault on read access to 0x0000002c at address 0x408661 (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x0000002c in 32-bit code (0x00408661). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00408661 ESP:0033dadc EBP:0033dbc0 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:00000111 ECX:00000000 EDX:00000002 ESI:0033dadc EDI:0033dbc0 Stack dump: 0x0033dadc: 00000001 0033f60c 00000111 cccccccc 0x0033daec: cccccccc cccccccc cccccccc cccccccc 0x0033dafc: cccccccc cccccccc cccccccc cccccccc 0x0033db0c: cccccccc cccccccc cccccccc cccccccc 0x0033db1c: cccccccc cccccccc cccccccc cccccccc 0x0033db2c: cccccccc cccccccc cccccccc cccccccc Backtrace: =>0 0x00408661 in bf2voicesetup (+0x8661) (0x0033dbc0) 1 0x00403978 in bf2voicesetup (+0x3978) (0x0033dd8c) 2 0x7c171915 in mfc71 (+0x31915) (0x0033ddbc) 3 0x7c14db36 in mfc71 (+0xdb36) (0x0033dde0) 4 0x7c175cd8 in mfc71 (+0x35cd8) (0x0033de30) 5 0x7c175cf2 in mfc71 (+0x35cf2) (0x0033dec4) .. --- snip --- The crash location is only indirectly related to the problem, hence this was a bit tricky to debug to the real cause. The real problem seems to be a Wine's winmm.mixerOpen() handling fdwOpen flags with CALLBACK_WINDOW when dwCallback is NULL. Consider the following (WINEDEBUG=+winmm): --- snip --- 0023:trace:winmm:DllMain 0x60380000 0x1 0x1 0023:trace:winmm:MMDRV_Init () .. 0023:trace:winmm:MIXER_Open (0x425f0c, 0, 00000000, 00000000, 00010000) .. --- snip --- mixerOpen() with CALLBACK_WINDOW flags and NULL dwCallback results in MMSYSERR_INVALPARAM. Corresponding Wine code: --- snip dlls/winmm/winmm.c:MIXER_Open --- UINT MIXER_Open(LPHMIXER lphMix, UINT uDeviceID, DWORD_PTR dwCallback, DWORD_PTR dwInstance, DWORD fdwOpen, BOOL bFrom32) { ... switch (fdwOpen & CALLBACK_TYPEMASK) { .. case CALLBACK_WINDOW: mod.dwInstance = dwCallback; if (!IsWindow((HWND)dwCallback)) return MMSYSERR_INVALPARAM; break; } .. } --- snip dlls/winmm/winmm.c:MIXER_Open --- MSDN: http://msdn.microsoft.com/en-us/library/ms712134.aspx It says: "The dwCallback parameter is assumed to be a window handle (HWND)." Unfortunately the app expects MMSYSERR_NOERROR but not a failure (bad app error handling anyway). Hence crucial data structures are not getting setup properly (C++ instances/member data), leading to NULL ptr dereference at much later time. A small conformance test case (fdwOpen=CALLBACK_WINDOW, dwCallback=NULL) should reveal this MSDN documentation insufficiency. 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 5

[Bug 16598] New: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=16598 Summary: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only Product: Wine Version: 1.1.10 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while doing some occasional end user support on #winehq (*yuck*), one user complained about wrc not compiling his .rc file. Visual C++ and mingw toolchains compiled it in Windows without problems but Wine's wrc didn't like it. --- snip --- ... resource.rc:114:31: Error: syntax error --- snip --- He sent me a link to the .rc file to have a look at. Relevant parts: Resource.rc: --- snip --- // Microsoft Visual C++ generated resource script. // #include "resource.h" #define APSTUDIO_READONLY_SYMBOLS ///////////////////////////////////////////////////////////////////////////// // // Generated from the TEXTINCLUDE 2 resource. // #include <windows.h> ///////////////////////////////////////////////////////////////////////////// #undef APSTUDIO_READONLY_SYMBOLS ... ///////////////////////////////////////////////////////////////////////////// // // Menu // IDR_MENU MENU BEGIN ... END ///////////////////////////////////////////////////////////////////////////// // // Dialog // IDD_MEMTRANSFER DIALOGEX 100, 100, 174, 90 STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "Memory Transfer" FONT 8, "Courier New", 0, 0, 0x0 BEGIN DEFPUSHBUTTON "&OK",IDOK,42,72,40,14 ... --- snip --- Resource.h: --- snip --- //{{NO_DEPENDENCIES}} // Microsoft Visual C++ generated include file. // Used by resource.rc // #define IDR_MENU 100 #define IDI_ICON 101 #define IDB_BITMAP 102 #define IDR_MAIN_ACCEL 103 #define IDD_MEMTRANSFER 104 ... --- snip --- The resource include chain is as follows: resource.h windows.h (due to RC_INVOKED defined by wrc) -> winresrc.h -> winuser.rh and commctrl.rh The problem is that winuser.rh defines only a subset of winuser.h control ids This breaks resource scripts which for example reference standard dialog button IDs. Telling the user to explicitly include <winuser.h> solved his problems. You might want to extend winuser.rh a bit to include often used standard control ids (ex: dialog button). 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 13399] New: Appdb doesn't remember logins
by wine-bugs＠winehq.org Oct. 11, 2011

Oct. 11, 2011

http://bugs.winehq.org/show_bug.cgi?id=13399 Summary: Appdb doesn't remember logins Product: WineHQ Apps Database Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tehblunderbuss(a)gmail.com The appdb doesn't remember logins, like how the bugzilla or wiki do. -- 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 7

[Bug 12939] New: >=wine-0.9.59: Selection using control key and mouse button does not work.
by wine-bugs＠winehq.org Oct. 11, 2011

Oct. 11, 2011

http://bugs.winehq.org/show_bug.cgi?id=12939 Summary: >=wine-0.9.59: Selection using control key and mouse button does not work. Product: WineHQ Bugzilla Version: unspecified Platform: PC URL: http://www.foobar2000.org OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: h.judt(a)gmx.at In Foobar2000, <Control>-<Mouse1> should select or deselect a single entry in the playlist. Instead, it just selects a new entry and deselects all others as if the control key has not been pressed. This worked in <wine-0.9.59 but does not in >=wine-0.9.59 (last version tested was 0.9.61). Similar problem with <Shift>-<Mouse1> existed in =wine-0.9.59, but was solved in >=0.9.60 and works fine now. Occurs with: Foobar2000-0.9.4.4, Exact Audio Copy-0.99prebeta4, file selector dialogs, but might effect other software / versions / dialogs as well. When I launch Foobar2000 and try to add files, I get the following messages on the terminal, maybe this is of some help: fixme:menu:TrackPopupMenuEx not fully implemented fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 -- 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 29

[Bug 21777] New: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...)
by wine-bugs＠winehq.org Oct. 11, 2011

Oct. 11, 2011

http://bugs.winehq.org/show_bug.cgi?id=21777 Summary: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...) Product: Wine Version: 1.1.39 Platform: x86 URL: http://www.tecdoc.de OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, at the end of TecDoc CATALOG 1/2010 DVD install a crash dialog is displayed while starting a service (the msi part of install is finished anyway). The database engine service has auto-start type set hence on every program start (wine notepad) the infamous crash dialog is displayed. This turns out to be an app bug but due to differences in Wine vs. Windows API design/usage this bug has no consequences in Windows and goes on unnoticed. Unfortunately the part of software that crashes comes from another software supplier "Transaction Software" (http://www1.transaction.de/transaction/) Many automotive spare parts catalogue software (BMW, VW, Audi, GM, Fiat ...) internally use the Transbase SQL database engine for years. In case of Wine/Linux this means many broken apps/versions in the wild due to this bug and even if the original software supplier fixes the bug, it will take years until spare parts catalogue software vendors using the engine to pick up and release new versions of their own products. Despite being an app bug I suggest to modify Wine to work around this developer stupidity. Here it goes, first the crash itself: --- snip --- wine: Unhandled page fault on read access to 0x012f0000 at address 0x681ee546 (thread 001d), starting debugger... Unhandled exception: page fault on read access to 0x012f0000 in 32-bit code (0x681ee546). ... Threads: process tid prio (all id:s are in hex) ... 00000019 (D) C:\TECDOC_CD\1_2010\db\tbmux32.exe 0000001d 0 <== 0000001b 0 0000001a 0 ... Backtrace: =>0 0x681ee546 (0x012eddd4) 1 0x7bc79ac0 NtCreateMutant+0xae(MutantHandle=0x12eded4, access=0x1f0001, attr=0x12edeb4, InitialOwner=0) [/opt/wine/wine-git/dlls/ntdll/sync.c:429] in ntdll (0x012ede94) 2 0x7b869dc8 CreateMutexExW+0xb2(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:653] in kernel32 (0x012edee4) 3 0x7b869d0c CreateMutexExA+0xb6(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:626] in kernel32 (0x012ee124) 4 0x7b869c08 CreateMutexA+0x3a(sa=0x12ee16c, owner=0, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)") [/opt/wine/wine-git/dlls/kernel32/sync.c:599] in kernel32 (0x012ee144) 5 0x0041a2a3 in tbmux32 (+0x1a2a3) (0x74fd9c13) 6 0x458d28ec (0x83e58955) --- snip --- Starting the whole thing (db service) with +relay exhibits a different behaviour: the service doesn't crash but it doesn't really work, indicating a stack usage problem. Have a close look at security descriptor dump, DACL part: --- snip --- 001e:Call advapi32.InitializeSecurityDescriptor(012ee2bc,00000001) ret=00419b06 001e:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=00419b06 001e:Call advapi32.InitializeAcl(012ede8c,00000400,00000002) ret=00419b28 001e:Ret advapi32.InitializeAcl() retval=00000001 ret=00419b28 001e:Call advapi32.InitializeSid(012eda8c,012eda84,00000001) ret=00419b47 001e:Ret advapi32.InitializeSid() retval=00000001 ret=00419b47 001e:Call advapi32.GetSidSubAuthority(012eda8c,00000000) ret=00419b60 001e:Ret advapi32.GetSidSubAuthority() retval=012eda94 ret=00419b60 001e:Call advapi32.AddAccessAllowedAce(012ede8c,00000002,10000000,012eda8c) ret=00419b7c 001e:Ret advapi32.AddAccessAllowedAce() retval=00000001 ret=00419b7c 001e:Call advapi32.SetSecurityDescriptorDacl(012ee2bc,00000001,012ede8c,00000000) ret=00419b9e 001e:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=00419b9e 001e:Call KERNEL32.CreateMutexA(012ee2b0,00000000,012ee2d0 "Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)") ret=0041a2a3 001e: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0018,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=unknown<156>,AceFlags=e2},{AceType=unknown<46>,AceFlags=1}}},name=L"Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)"} ) 001e: create_mutex() = INVALID_SECURITY_DESCR { handle=0000 } 001e:Ret KERNEL32.CreateMutexA() retval=00000000 ret=0041a2a3 --- snip --- Pretty much messed up. To keep the story short, I translated debugger disassembly snippets and annotated stack dumps into a snippet of C code so you won't get annoyed with too much detail ;-) This is most likely what the app does (might not be 100% accurate, just to illustrate the problem): --- stupid app code start --- static int prepare_sd( SECURITY_ATTRIBUTES *sa) { SID_IDENTIFIER_AUTHORITY sia_world = SECURITY_WORLD_SID_AUTHORITY; BYTE user_sid[0x400]; BYTE acl_buffer[0x400]; int res = InitializeSecurityDescriptor( sa->lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION); if( !retval) return res; res = InitializeAcl( (PACL) acl_buffer, sizeof(acl_buffer), ACL_REVISION); if( !retval) return res; res = InitializeSid( (PSID) user_sid, &sia_world, 1); if( !retval) return res; *GetSidSubAuthority( (PSID) user_sid, 0) = SECURITY_WORLD_RID; res = AddAccessAllowedAce( (PACL) acl_buffer, ACL_REVISION, 0x10000000, (PSID) user_sid); if( !retval) return res; return SetSecurityDescriptorDacl( sa->lpSecurityDescriptor, TRUE, (PACL)acl_buffer, FALSE); } static int open_app_mutex( ...) { SECURITY_DESCRIPTOR sd; SECURITY_ATTRIBUTES sa = {0}; char name[0x80]; wsprintfA( name, "xxx", ...); sa.nLength= sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = FALSE; prepare_sd( &sa); CreateMutexA( &sa, FALSE, name); ... } --- stupid app code end --- You can probably spot the biggest mistake of all pretty soon: some "genius" decided to put everything on stack in prepare_sd(). Upon return of prepare_sd() helper function, the stack locals used within prepare_sd() are still *intact* When the app calls CreateMutexA(), the call sequence is as follows: CreateMutexA -> CreateMutexExA -> CreateMutexExW -> NtCreateMutant --- snip dlls/kernel32/sync.c --- HANDLE WINAPI CreateMutexA( SECURITY_ATTRIBUTES *sa, BOOL owner, LPCSTR name ) { return CreateMutexExA( sa, name, owner ? CREATE_MUTEX_INITIAL_OWNER : 0, MUTEX_ALL_ACCESS ); } ... HANDLE WINAPI CreateMutexExA( SECURITY_ATTRIBUTES *sa, LPCSTR name, DWORD flags, DWORD access ) { WCHAR buffer[MAX_PATH]; if (!name) return CreateMutexExW( sa, NULL, flags, access ); if (!MultiByteToWideChar( CP_ACP, 0, name, -1, buffer, MAX_PATH )) { SetLastError( ERROR_FILENAME_EXCED_RANGE ); return 0; } return CreateMutexExW( sa, buffer, flags, access ); } --- snip dlls/kernel32/sync.c --- The problem is buried within CreateMutexExA(): the A to W conversion uses a stack based buffer of MAX_PATH len. This eats stack, partly overwriting the ACL buffer (DACL) from previous prepare_sd() which used to be a stack local too. The reason that this doesn't happen on Windows is most likely conversions are heap based or the call path to kernel mode is very short, not consuming that much stack as Wine does. I verified with a patch to use heap based buffer in CreateMutexExA() for A to W conversion (similar what's being done in CreateMailslotA()) and it lets the app succeed despite that nasty stack bug. I'll leave it to Alexandre to judge this (change or leave Wine as it is). If you decide for WONTFIX (that app bug would really deserve such treatment), I will attach a patch to give users a chance work around various broken transbase versions. 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