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

[Bug 14698] Mordor: the Depths of Dejenol crashes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14698 --- Comment #1 from Per Christian Henden <perchrh-wine(a)pvv.org> 2008-07-30 16:25:03 --- Created an attachment (id=15182) --> (http://bugs.winehq.org/attachment.cgi?id=15182) output of WINEDEBUG=warn+all wine MORDOR.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 30, 2008

[Bug 14698] New: Mordor: the Depths of Dejenol crashes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14698 Summary: Mordor: the Depths of Dejenol crashes Product: Wine Version: 1.1.2 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: perchrh-wine(a)pvv.org Summary: Game crashes with stacktrace, I got debug logs. By installing the game in Windows (installer not working, bug #14696) and running the installed version (it just extracts and copies some files around) and renaming c:\windows\WAVEMIX.INI (to avoid bug #5349) I was able to start the game. The problem occurs when you click 'run' after selecting a character. -- 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 30, 2008

[Bug 14696] Mordor: the Depths of Dejenol fails to install (regression)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14696 --- Comment #1 from Lei Zhang <thestig(a)google.com> 2008-07-30 15:38:34 --- Can you try Wine 0.9.58 and make sure it is a regression? If so, please run a regression test: http://wiki.winehq.org/RegressionTesting -- 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 30, 2008

[Bug 14697] New: wineserver: debug events can block completion of queued user APCs

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14697 Summary: wineserver: debug events can block completion of queued user APCs Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, consider the following scenario... A debugger is attached to a debuggee. The debuggee has two threads. The debugger processes debug events and queries virtual memory info of remote process using VirtualQueryEx in its main loop. VirtualQueryEx -> NtQueryVirtualMemory -> enqueues APC_VIRTUAL_QUERY user APC for remote process (debuggee). The calling thread is blocked until the APC is completed. Following is the "good" case: tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) --- snip --- .. 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=0x7fff0000} ) 001a: *wakeup* signaled=192 cookie=0x7ffdb7b4 0009: queue_apc() = 0 { handle=0x68, self=0 } 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=1c8f097946d2824 (-0.1787600), result={}, handles={} ) 001a: select() = USER_APC { apc_handle=0x68, timeout=1c8f097946d2824 (-0.1787600), call={APC_VIRTUAL_QUERY,addr=0x7fff0000} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=0x68, timeout=1c8f097946d2824 (-0.1792110), result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0}, handles={} ) 0009: *wakeup* signaled=0 cookie=0x32d30c 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f097946d2824 (-0.1792110), call={APC_NONE} } 0009: get_apc_result( handle=0x68 ) 0009: get_apc_result() = 0 { result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0} } --- snip --- Now the interesting one, which ultimately leads to block of calling thread ... tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) tid=001b (debuggee thread 2) --- snip --- 0009: continue_debug_event( pid=0019, tid=001a, status=65538 ) 001a: *wakeup* signaled=258 cookie=0x7ffdb7b4 001b: *wakeup* signaled=258 cookie=0x7ffd77b4 0009: continue_debug_event() = 0 .. 0009: read_process_memory( handle=0x54, addr=0x7ffd8000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data= {} } 0009: read_process_memory( handle=0x54, addr=0x7ffd4000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data={} } 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=(nil)} ) 001b: *wakeup* signaled=192 cookie=0x7ed44874 0009: queue_apc() = 0 { handle=0x68, self=0 } 001a: load_dll( handle=(nil), base=0x61090000, size=102400, dbg_offset=0, dbg_size=0, name=0x13e468, filename=L"C:\\windows\\system32\\msacm32.dll" ) 001a: *sent signal* signal=10 001b: *sent signal* signal=10 001a: load_dll() = 0 .. 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001a: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ed44874, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x4c} ) 001b: select() = USER_APC { apc_handle=0x68, timeout=infinite, call={APC_VIRTUAL_QUERY,addr=(nil)} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c8b694 (+0.0000000), call={APC_NONE} } 001b: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001b: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ffd77b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001b: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c90dc4 (+0.0000000), call={APC_NONE} } ... --- snip --- At this point, tid=0009 (debugger) is blocked forever. When the APC_VIRTUAL_QUERY user APC is queued, remote thread 001b is selected/destined to carry out the APC. After thread 001a and 001b woke up, a dynamic library is loaded from thread 001a which results in LOAD_DLL_DEBUG_EVENT dispatched. This initiates the suspension of all threads in the child process (SIGUSR1 is sent for 001a and 001b). Thread 001a is suspended first, 001b next. The suspension of 001b happens to a time when 001b is about to carry out the APC_VIRTUAL_QUERY. Meanwhile thread 0009 (calling process) is waiting for APC completion result forever because it's blocked by VirtualQueryEx in debugger loop, unable to receive and process any debug event. 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 30, 2008

[Bug 9221] Force Feedback doesn't work but does after little source modification

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9221 --- Comment #19 from Chris Henhawke <chris(a)hamiltonshells.ca> 2008-07-30 14:30:09 --- Unfortunately the Logitech G25's force feedback isn't supported by the kernel yet, so I won't be able to test until that happens. Thanks for the update Vitaliy. :) -- 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 30, 2008

[Bug 14696] New: Mordor: the Depths of Dejenol fails to install (regression)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14696 Summary: Mordor: the Depths of Dejenol fails to install (regression) Product: Wine Version: 1.1.2 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: perchrh-wine(a)pvv.org Created an attachment (id=15181) --> (http://bugs.winehq.org/attachment.cgi?id=15181) output of WINEDEBUG=warn+all The installation starts okay when I do the wine.inf change required to load ddeml.dll (bug 7326) and set the windows version to Win95. Then it tries to extract files from some .WIP files using the UNWIP.EXE and fails. A message from "Setup Unzipper" shows "Errors encountered: 0". My guess is that running UNWIP.EXE results in an error, as the string "Setup Unzipper" is found in the UNWIP.EXE. Attaching the debug logs from start up to the error (the action starts at about line 530). $> file unwip.exe says: unwip.exe: MS-DOS executable, NE for MS Windows 3.x Reading the test reports for the game in wine appdb, it says that the game installed using version 0.9.58 of wine, so this looks like a regression. -- 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 30, 2008

[Bug 14689] WoW using OpenGL runs slow

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14689 --- Comment #6 from Alexander Keusch <a.keusch(a)gmx.at> 2008-07-30 14:21:40 --- /usr/lib32/libGL.so.* is available: # ls -l /usr/lib32/libGL.so.* lrwxrwxrwx 1 root root 12 2008-07-24 14:18 /usr/lib32/libGL.so.1 -> libGL.so.1.2 -rw-r--r-- 1 root root 483332 2008-07-24 14:16 /usr/lib32/libGL.so.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 30, 2008

[Bug 14689] WoW using OpenGL runs slow

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14689 --- Comment #5 from Lei Zhang <thestig(a)google.com> 2008-07-30 13:43:46 --- Do you have /usr/lib32/libGL.so.* ? If they don't exist, then Wine (a 32-bit app) won't be able to find the openGL libraries it needs, whereas glxinfo (a 64-bit app) will find 64-bit libGL in /usr/lib. -- 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 30, 2008

[Bug 10120] Oblivion lines in water (regression)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10120 --- Comment #16 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-30 13:03:44 --- However I found out this: With wine-1.1.0 and ORM=fbo the lines don't appear and the performance isn't all that bad. wine-1.1.0, ORM=pbuffer: lines wine-1.1.0, ORM=backbuffer: lines To it seems like fbo fixes this problem, but it's currently broken because of the patches discussed here: http://bugs.winehq.org/show_bug.cgi?id=14038 -- 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 30, 2008

[Bug 10120] Oblivion lines in water (regression)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10120 --- Comment #15 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-30 12:58:16 --- Deconfirming. Tried it with all available ORM modes. None of them has the issue fixed. With fbo it doesn't even render correctly, plus the performance is a disaster (seems like Morrowind is also affected by the NP2 changes, that also affect MP2 rendering performance with NVFX cards). -- 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 30, 2008