July 2008 - Wine-Bugs - list.winehq.org

[Bug 9473] Adobe Reader 6 / Adobe Acrobat Pro 6: Zoomfactor and Pagenumber are empty (riched20.dll)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9473 --- Comment #11 from foobard <jens(a)porup.com> 2008-07-27 10:37:03 --- In 1.1.2, with a fresh download of Acrobat Reader 6 and a clean .wine, Acrobat Reader 6 no longer runs. Console output with backtrace attached. -- 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.

July 27, 2008

[Bug 9473] Adobe Reader 6 / Adobe Acrobat Pro 6: Zoomfactor and Pagenumber are empty (riched20.dll)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9473 --- Comment #10 from foobard <jens(a)porup.com> 2008-07-27 10:36:41 --- Created an attachment (id=15094) --> (http://bugs.winehq.org/attachment.cgi?id=15094) console output when acrobat 6 fails -- 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.

July 27, 2008

[Bug 14509] RegGetValue sometimes doesn't work properly

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14509 Mathias Kosch <info(a)mkosch.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #6 from Mathias Kosch <info(a)mkosch.de> 2008-07-27 10:29:10 --- Is working since version 1.1.2. -- 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.

July 27, 2008

[Bug 10503] Sid Meier's Alpha Centauri: Wine segfaults when clicking on a city.

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10503 Mikolaj Zalewski <mikolaj.zalewski(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikolaj.zalewski(a)gmail.com --- Comment #20 from Mikolaj Zalewski <mikolaj.zalewski(a)gmail.com> 2008-07-27 10:26:06 --- If I understand correctly, the exception is caused because of DIB access. A DIB can be accesses ilike normal memory or using GDI calls. Wine uses the X server for GDI calls - to e.g. draw a line, we upload the content to the server, mark the memory area as protected and make the server draw the line. When the program tries to access this area like memory, this generates an exception, we catch it, download the updated content from the server, unprotect the memory and resume the program. As it was written, the problem is that the program abuses the ESP register while doing DIB operations, what makes the exception not to work. Solving it doesn't look like something feasible for a newbie hacker. The best solution would be to have a DIB engine for in-process GDI manipluations. I've heard it is being worked on. This will avoid this DIB sections ping-pong and exceptions being generated. But that's a large piece of code that needs to be integrated properly with the rest of Wine. Other possible solution would be to check if Windows have some mechanisms to raise exceptions even if ESP is invalid. However I don't think so - the exception handling is closely related to stack unwinding. But maybe vectored handlers are special? We could also have a special stack for DIB exceptions but if that is not a Windows feature that it probably won't be accepted because of being a hack. -- 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.

July 27, 2008

[Bug 14186] Morrowind stucks for 3-5seconds during background music change (in combat)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14186 Oisin O Malley <ninja.gofer(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #9 from Oisin O Malley <ninja.gofer(a)gmail.com> 2008-07-27 10:16:19 --- *** This bug has been confirmed by popular vote. *** -- 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.

July 27, 2008

[Bug 14656] voipdiscount cannot connect

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14656 --- Comment #3 from Hans Leidekker <hans(a)it.vu.nl> 2008-07-27 09:54:28 --- I played with this app for a bit and it looks as if DNS is flaky for voipdiscount.com. Please try with this line added to your /etc/hosts file: 194.120.0.223 client.voipdiscount.com Does that change anything? -- 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.

July 27, 2008

[Bug 14661] New: Cannot accept ToS For the WoW:WotLK Beta

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14661 Summary: Cannot accept ToS For the WoW:WotLK Beta Product: Wine Version: 1.1.2 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ryuzaki90(a)gmail.com Not sure if it uses the same "scroll to bottom and click accept" mechanic as the BC installer, or the WoW base installer, haven't tested lately... but it basically stops me from installing the game. Scroll to the bottom as required to accept, the accept button is still grayed. -- 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.

July 27, 2008

[Bug 13915] Oblivon Script Extender (OBSE) fails to start ("privileged instruction")

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13915 Rob Whalley <mail(a)robwhalley.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail(a)robwhalley.co.uk --- Comment #3 from Rob Whalley <mail(a)robwhalley.co.uk> 2008-07-27 09:33:13 --- Tested with: Ubuntu 8.04 64-bit Wine version v1.1.1 (Git version) OBSE: v0015 Latest patched version of Oblivion (original retail CD only, no expansion packs) Error when using command 'wine obse_loader.exe' to start: "wine: Unhandled page fault on read access to 0x00000010 at address 0x7ebefd6e (thread 0017), starting debugger... Unhandled exception: page fault on read access to 0x00000010 in 32-bit code (0x7ebefd6e)." Attached terminal output. -- 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.

July 27, 2008

[Bug 13915] Oblivon Script Extender (OBSE) fails to start ("privileged instruction")

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13915 --- Comment #2 from Rob Whalley <mail(a)robwhalley.co.uk> 2008-07-27 09:32:32 --- Created an attachment (id=15093) --> (http://bugs.winehq.org/attachment.cgi?id=15093) Terminal output of 'wine obse_loader.exe' -- 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.

July 27, 2008

[Bug 12948] zmud does not run under Ubuntu 8.04 (...turn off system debuggers)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=12948 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> 2008-07-27 09:01:25 --- Hello, I found the problem ... prepare for journey into debuggers and race conditions ;-) In short: it's a bug in the software protection code which the application is bundled with - not fixable in Wine. Prerequisite: - enable wineserver tracing which slows it down sufficiently to observe and log the behaviour - "pre-start" wineserver with a console program (cmd.exe) just to let it sit and wait Following are relevant process/thread ids to follow snippets: --- snip --- process tid prio (all id:s are in hex) .. 00000017 0000001b 2 'Zmud.exe' (father, acting as debugger) 00000018 1 'Zmud.exe' (father, acting as debugger) 00000019 0000001a 1 'Zmud.exe' (child, debuggee) .. --- snip --- The father - which will act as debugger later - creates the child process. The child is created as "suspended" (hence the CREATE_SUSPENDED flags): --- snip --- 0018: new_process( inherit_all=1, create_flags=00000004, socket_fd=16, exe_file=0x44, hstdin=0x4, hstdout=0x8, hstderr=0xc, process_access=001f0fff, process_attr=00000000, thread_access=001f03ff, thread_attr=00000000, info={AllocationSize=1000,Size=5e4,Flags=0,DebugFlags=0,ConsoleHandle=(nil),ConsoleFlags=0,hStdInput=0x4,hStdOutput=0x8,hStdError=0xc,CurrentDirectory.Handle=(nil),dwX=0,dwY=0,dwXSize=0,dwYSize=0,dwXCountChars=0,dwYCountChars=0,dwFillAttribute=0,dwFlags=0,wShowWindow=1,CurrentDirectory.DosPath=L"C:\\Program Files\\zMUD\\",DllPath=L"C:\\Program Files\\zMUD;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;C:\\windows\\system32;C:\\windows",ImagePathName=L"C:\\Program Files\\zMUD\\Zmud.exe",CommandLine=L"./Zmud.exe",WindowTitle=L"",Desktop=L"",ShellInfo=L"",RuntimeInfo=L""}, ... 0018: new_process() = 0 { info=0x48, pid=0019, phandle=0x4c, tid=001a, thandle=0x50 } --- snip --- The main thread of the child gets created and process init is done: --- snip --- 001a: init_thread( unix_pid=17405, unix_tid=17405, debug_level=0, teb=0x7ffd8000, peb=0x7ffdf000, entry=(nil), ldt_copy=0x601239e0, reply_fd=5, wait_fd=7 ) 001a: init_thread() = 0 { pid=0019, tid=001a, info_size=7598, server_start=1c8efe01f98c966 (-3.6957770), version=341 } ... 001a: init_process_done( module=0x400000, entry=0x94ef73, gui=1 ) 0018: *wakeup* signaled=0 cookie=0x16dd154 001a: *sent signal* signal=10 001a: init_process_done() = 0 --- snip --- After the create process call returns, the father rewrites entry point in the child with an 0xEB, 0xFE opcode sequence which is basically a jump to itself. Remember: PE entry point is not executed yet due to suspended creation. This opcode sequence will let the child enter an endless loop when the main thread of the child process is resumed and the location is hit. --- snip --- 0018: get_new_process_info( info=0x48 ) 0018: get_new_process_info() = 0 { success=1, exit_code=259 } .. 0018: read_process_memory( handle=0x4c, addr=0x94ef73 ) .. 0018: write_process_memory( handle=0x4c, addr=0x94ef73, data={eb,fe} ) .. 0018: resume_thread( handle=0x50 ) 0018: resume_thread() = 0 { count=1 } --- snip --- The father continuously suspends child's main thread, fetching thread context and resumes it again until the EIP of rewritten code is reached: --- snip --- 0018: suspend_thread( handle=0x50 ) 001a: *sent signal* signal=10 0018: suspend_thread() = 0 { count=0 } 0018: get_thread_context( handle=0x50, flags=00010001, suspend=0 ) 0018: get_thread_context() = PENDING { self=0, context={} } 001a: set_thread_context( .. 001a: set_thread_context() = 0 { self=1 } 0018: suspend_thread( handle=0x50 ) 0018: suspend_thread() = 0 { count=1 } 0018: get_thread_context( handle=0x50, flags=00010001, suspend=0 ) 0018: get_thread_context() = 0 { ... } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001a: select() = PENDING { apc_handle=(nil), timeout=1c8efe0224574ac (+0.0000000), call={APC_NONE} } 0018: resume_thread( handle=0x50 ) 0018: resume_thread() = 0 { count=2 } 0018: resume_thread( handle=0x50 ) 001a: *wakeup* signaled=258 cookie=0x7ffdb7b4 0018: resume_thread() = 0 { count=1 } .. --- snip --- When the child entered the endless loop, the father will attach to the child process to receive debug events. >From now on, the father acts as debugger. --- snip --- 0018: debug_process( pid=0019, attach=1 ) 001a: *signal* signal=19 0018: debug_process() = 0 --- snip --- Next, the father restores the overwritten sequence with original code and resumes the child: --- snip --- 001a: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 001a: get_thread_context() = 0 { self=1, context= .. 0018: suspend_thread( handle=0x50 ) 0018: suspend_thread() = 0 { count=0 } 0018: write_process_memory( handle=0x4c, addr=0x94ef73, data={55,8b} ) 001a: *signal* signal=19 0018: write_process_memory() = 0 0018: new_thread( access=001f03ff, attributes=00000000, suspend=1, request_fd=14 ) 0018: *fd* 14 <- 71 0018: new_thread() = 0 { tid=001b, handle=0x5c } ... 0018: resume_thread( handle=0x5c ) 001b: *wakeup* signaled=258 cookie=0x7ffd77b4 0018: resume_thread() = 0 { count=1 } --- snip --- The child begins to execute entry code, this is the problematic section (explanation later): --- snip --- 001a: open_mutex( access=001f0001, attributes=00000000, rootdir=0x24, name=L"19::DA0D2092E0" ) 001a: open_mutex() = OBJECT_NAME_NOT_FOUND { handle=(nil) } 001a: open_mutex( access=001f0001, attributes=00000000, rootdir=0x24, name=L"19::DA0D2092E0" ) 001a: open_mutex() = OBJECT_NAME_NOT_FOUND { handle=(nil) } 001a: set_thread_info( handle=0xfffffffe, mask=1, priority=1, affinity=00000000, token=(nil) ) 001a: set_thread_info() = 0 001a: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0x24,sd={},name=L"19:DAF"} ) 001a: create_mutex() = 0 { handle=0x40 } --- snip --- The father enters its debugger loop and receives first debug events: --- snip --- 0018: get_process_info( handle=0x4c ) 0018: get_process_info() = 0 { pid=0019, ppid=0017, exit_code=259, priority=2, affinity=ffffffff, peb=0x7ffdf000, start_time=1c8efe021cc4f50 (-0.8118270), end_time=0 } 0018: wait_debug_event( get_handle=1 ) 0018: wait_debug_event() = 0 { pid=0019, tid=001a, wait=(nil), event={create_process,file=0x54,process=0x44,thread=0x48,base=0x400000,offset=0,size=0,teb=0x7ffd8000,start=(nil),name=0x110618,unicode=1} } --- snip --- After receiving the "create process" event, the father creates some mutexes (the child will look for it): --- snip --- 0018: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0x14,sd={},name=L"19::DA0D2092E0"} ) 0018: create_mutex() = 0 { handle=0x64 } 0018: resume_thread( handle=0x50 ) 0018: resume_thread() = 0 { count=1 } 0018: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0x14,sd={},name=L"DILLOCREATE"} ) 0018: create_mutex() = 0 { handle=0x68 } 0018: close_handle( handle=0x68 ) 0018: close_handle() = 0 0018: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0x14,sd={},name=L"DILLOOEP"} ) 0018: create_mutex() = 0 { handle=0x68 } --- snip --- Some time later in child process code: --- snip --- 001a: open_mutex( access=001f0001, attributes=00000000, rootdir=0x24, name=L"19:DAF" ) 001a: open_mutex() = 0 { handle=0x74 } .. 001a: set_window_text( handle=0x10028, text=L"Error!" ) 001a: set_window_text() = 0 --- snip --- Well, what happens? The mutexes are the critical point, they serve to synchronize father and child startup phases. Unfortunately there is a race condition which allows the child to create a mutex which it is not allowed to (due to absence of certain father-created mutexes) which leads to this error. Remember the point when the father attached to the child and restores the original entry point code? As soon as the father resumes the execution of the child's main thread, the child begins to execute further. At the same time the father enters it's main debugging loop, waiting to receive first debug events. This is actually the race: the "process creation" event might be a bit too late when the child already executed some chunk of code. The problem can be prevented by not resuming child's main thread before entering debugger event loop/creating mutexes. Another solution whould be to guard the page at restored opcode location to let any execution immediately cause page guard exception which would ideally suspend the child thread again (like the protector does for the rest of code to decrypt/encrypt code pages on the fly). When the debugger loop is entered it would receive process creation and page guard exception event serialized and coulde handle it appropriately. 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.

July 27, 2008