August 2018 - Wine-Bugs - list.winehq.org

[Bug 41835] New: lg dvd firmware updater crashes
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=41835 Bug ID: 41835 Summary: lg dvd firmware updater crashes Product: Wine Version: 1.8.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: oswald.buddenhagen(a)gmx.de Distribution: Debian Created attachment 56254 --> https://bugs.winehq.org/attachment.cgi?id=56254 crash dump encouraged by some success stories relating to similar procedures, i tried updating the firmware of my dvd-rw drive with the updater from http://www.lg.com/us/support-product/lg-GH22NS30 (i tried both the 2.00 and 1.03 versions). however, the program crashes at startup. the crash is in the application itself, but it's undoubtedly the result of some inaccuracy in wine. i tried both 1.8.5 and 1.9.x. -- 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 38396] New: msiexec crash with winetricks running LEGOHarryPotter
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=38396 Bug ID: 38396 Summary: msiexec crash with winetricks running LEGOHarryPotter Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: ribeirws(a)gmail.com Distribution: --- Created attachment 51249 --> https://bugs.winehq.org/attachment.cgi?id=51249 Backtrace of the bug msiexec crash with winetricks running LEGOHarryPotter msiexec crash with winetricks running LEGOHarryPotter -- 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 8

[Bug 35999] New: Need for speed carbon DEMO all keyboard keys not working X11DRV_KEYBOARD
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

http://bugs.winehq.org/show_bug.cgi?id=35999 Bug ID: 35999 Summary: Need for speed carbon DEMO all keyboard keys not working X11DRV_KEYBOARD Product: Wine Version: 1.7.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jarkko_korpi(a)hotmail.com I was testing NFS Carbon because of another bug. And I used warn all debug. While in game I noticed that I can't control the car with arrow keys. This is not the only game I have this issue. Some splinter cell games, NFS, RAW (wrestling game demo) and maybe some other have had similar issue, which has mostly corrected by installing input overrides. While debugging another error I found these lines: warn:keyboard:X11DRV_KEYBOARD_DetectLayout 7 keysyms per keycode not supported, set to 4 warn:keyboard:X11DRV_KEYBOARD_DetectLayout Using closest match (Swedish keyboard layout) for scan/virtual codes mapping. Closest match? It should be finnish keyboard... warn:keyboard:X11DRV_InitKeyboard vkey 010D is being used by more than one keycode warn:keyboard:X11DRV_InitKeyboard vkey 0124 is being used by more than one keycode warn:keyboard:X11DRV_InitKeyboard vkey 0126 is being used by more than one keycode and few similar lines. Wine 1.7.16 -- 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 6

[Bug 45649] New: chromium x32 sandbox hangs forever inside server_queue_process_apc
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=45649 Bug ID: 45649 Summary: chromium x32 sandbox hangs forever inside server_queue_process_apc Product: Wine Version: 3.13 Hardware: x86 OS: Linux Status: NEW Keywords: patch Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 62078 --> https://bugs.winehq.org/attachment.cgi?id=62078 0009-ntdll-Hack-to-prevent-freeze-in-NtProtectVirtualMemo.patch Follow up to bug 45648. For x32 chromium, the sandbox calls VirtualProctectEx for another process. It then reaches NtWaitForSingleObject( handle, FALSE, NULL ) in server_queue_process_apc, and waits there forever. Don't know why yet, but I attached a hack to work around the issue. -- 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 40373] New: Double free in RPCRT4
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=40373 Bug ID: 40373 Summary: Double free in RPCRT4 Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: UNCONFIRMED Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)winehq.org Reporter: timo.kreuzer(a)web.de Created attachment 54078 --> https://bugs.winehq.org/attachment.cgi?id=54078 idl file RPCRT4 can double free parameter allocations from NdrStubCall2 The specific situation where this happened is the following: - The idl file was lsa.idl from ReactOS (file attached) - The function was LsarRetrievePrivateData - The parameter was EncryptedData - It happened in cleanup of marshalled parameters within NdrStubCall2, after calling this function What happened: - NdrStubCall2 iterates though the marshaling phases - On STUBLESS_MUSTFREE: - params[i].attr.MustFree is TRUE for parameter i = 2 (EncryptedData) - call_freer() is invoked with a pointer pointing to the parameter (pointer to the parameter location!) - param->attr.IsByValue is FALSE, so pMemory = *(unsigned char **)pMemory; pMemory is now equal to the value EncryptedData (a pointer to a pointer) - NdrFreer[pFormat[0] & NDR_TABLE_MASK] (NdrPointerFree) is called - NdrPointerFree calls PointerFree - desc = pFormat + *(const SHORT*)pFormat; - (attr & RPC_FC_P_DEREF) is TRUE, so current_pointer = *(unsigned char**)Pointer; (In the observed case this is NULL, since the function returned NULL in that OUT parameter) - NdrFreer[*desc & NDR_TABLE_MASK] (NdrPointerFree) is called with current_pointer (doing nothing, since it's NULL) - Pointer is not within pStubMsg->Buffer - attr & RPC_FC_P_ONSTACK is not set (this is different on midl!) - NdrFree(pStubMsg, Pointer) is called, freeing the pointer - On STUBLESS_FREE: - params[i].attr.ServerAllocSize is != 0 - HeapFree(GetProcessHeap(), 0, *(void **)pArg) is called on the pointer that was freed before. I cannot say exactly what is wrong here, but I see 2 potential problems: - The type for the parameter has different flags between midl and widl (the parameter data is the same), where widl is missing the [alloced_on_stack] flag: midl: /* 2076 */ 0x11, 0x14, /* FC_RP [alloced_on_stack] [pointer_deref] */ /* 2078 */ NdrFcShort( 0xffb6 ), /* Offset= -74 (2004) */ widl: /* 3112 (PLSAPR_CR_CIPHER_VALUE *) */ 0x11, 0x10, /* FC_RP [pointer_deref] */ NdrFcShort(0xfffa), /* Offset= -6 (3108) */ With this flag, the parameter is not freed, but that might not be the correct solution. - Parameters with ServerAlloc are allocated from the heap, while according to https://msdn.microsoft.com/library/windows/desktop/aa374362%28v=vs.85%29.as…, it should be allocated on the stack, so it would not be freed. -- 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 2

[Bug 37279] New: builtin IE "document.location.pathname" returns without leading slash
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=37279 Bug ID: 37279 Summary: builtin IE "document.location.pathname" returns without leading slash Product: Wine Version: 1.7.26 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: penghao(a)linuxdeepin.com Created attachment 49577 --> https://bugs.winehq.org/attachment.cgi?id=49577 test case I have upload a test html page, use jscript to get value of document.location.pathname. if it was start with a leading slash, nothing will happen; if don't, will be a alert. this page was tested on IE8/11, Chrome, Firefox. they are all right. but in builtin IE the value will do not have leading slash. -- 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 10

[Bug 34021] New: IE8 crashes badly when navigating to www.microsoft.com
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

http://bugs.winehq.org/show_bug.cgi?id=34021 Bug #: 34021 Summary: IE8 crashes badly when navigating to www.microsoft.com Product: Wine Version: 1.6-rc4 Platform: x86-64 URL: http://download.microsoft.com/download/C/C/0/CC0BD555- 33DD-411E-936B-73AC6F95AE11/IE8-WindowsXP-x86-ENU.exe OS/Version: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: wininet AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Classification: Unclassified Created attachment 45209 --> http://bugs.winehq.org/attachment.cgi?id=45209 wine-1.6-rc4-122-g104adb7 console output (caught by redirects) Working around Bug 25648, "wine ~/.wine/drive_c/Program\ Files/Internet\ Explorer/iexplore.exe www.microsoft.com" crashes out badly. See logs. However, workaround is supplied wininet (and urlmon - unimplemented function). -- 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 10

[Bug 43207] New: Friday The 13th The Game not Working
by wine-bugs＠winehq.org June 10, 2019

June 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=43207 Bug ID: 43207 Summary: Friday The 13th The Game not Working Product: Wine-staging Version: 2.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tall89(a)mail.ru CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- When you try to start EAC_Launcher.exe, the following error gets out: - REVOLT.nfo was eitner deleted or not put in directory. Application will terminate now WINEDEBUG=fixme-all,err+loaddll,err+dll,err+file,err+reg ------ Program EAC_Launcher.exe ------ err:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request failed with status 0x2733 err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.0.102:5353 16 aspire89-P55A-UD4.local. AAAA FE80:0000:0000:0000:0A12:F0CA:1A84:437A" err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: ProbeCount 2; will deregister 4 aspire89-P55A-UD4.local. Addr 192.168.0.102" err:eventlog:ReportEventW L"Local Hostname aspire89-P55A-UD4.local already in use; will try aspire89-P55A-UD4-2.local instead" err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.0.102:5353 25 102.0.168.192.in-addr.arpa. PTR aspire89-P55A-UD4.local." err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Unexpected conflict discarding 27 102.0.168.192.in-addr.arpa. PTR aspire89-P55A-UD4-2.local." err:winedevice:async_create_driver failed to create driver L"ps6ajtsb": c0000135 -- 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 42868] New: Ether One Redux: graphical glitches/ miscoloration when running the game in DirectX mode
by wine-bugs＠winehq.org June 9, 2019

June 9, 2019

https://bugs.winehq.org/show_bug.cgi?id=42868 Bug ID: 42868 Summary: Ether One Redux: graphical glitches/miscoloration when running the game in DirectX mode Product: Wine Version: 2.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fjfrackiewicz(a)gmail.com Distribution: --- Created attachment 57977 --> https://bugs.winehq.org/attachment.cgi?id=57977 Terminal output Wine-2.6-108-g6c7760f217 Ether One Redux, when ran in DirectX mode, suffers from graphic glitches and miscoloration on random objects. Fortunately enough, the game will display everything correctly when I use the "wine EtherOne.exe -opengl4" command which allowed me to make comparison shots for the glitched objects and how they are supposed to look. I am running the game in a clean Windows 7 64-bit prefix on an Nvidia 970 using the proprietary drivers (version 378.13). -- 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 10

[Bug 43340] New: valgrind shows several possible leaks in several tests ( e.g., dlls/amstream/tests/amstream.c) (AMD+llvm mesa)
by wine-bugs＠winehq.org June 9, 2019

June 9, 2019

https://bugs.winehq.org/show_bug.cgi?id=43340 Bug ID: 43340 Summary: valgrind shows several possible leaks in several tests (e.g., dlls/amstream/tests/amstream.c) (AMD+llvm mesa) Product: Wine Version: 2.12 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: --- Glx info: OpenGL renderer string: Gallium 0.4 on AMD OLAND (DRM 2.49.0 / 4.9.33-vanilla-workstation-3, LLVM 3.9.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.6 OpenGL core profile shading language version string: 4.50 OpenGL version string: 3.0 Mesa 17.0.6 Henri and I briefly discussed on IRC, not likely an issue: <wizardedit> strfllw, looking at valgrind + mesa with debugging info fixed (march disabled); I see a lot of possible leaks, could you take a quick look please? e.g., d3d10core/device: https://pastebin.com/URY5kwxu <strfllw> wizardedit: I'd have to take a much closer look to say for sure, but purely by "gut feeling" I'd say probably not <strfllw> my guess would be valgrind not understanding ralloc in the first one, and not understanding Mesa's shader cache for the others Filing a bug for reference / place holder in case someone does want to investigate. ../../../tools/runtest -q -P wine -T ../../.. -M amstream.dll -p amstream_test.exe.so amstream && touch amstream.ok ==25729== 252 bytes in 1 blocks are possibly lost in loss record 2,505 of 3,085 ==25729== at 0x402C267: malloc (vg_replace_malloc.c:299) ==25729== by 0x6928B70: ralloc_size (ralloc.c:126) ==25729== by 0x6928C8E: rzalloc_size (ralloc.c:158) ==25729== by 0x6928151: _mesa_hash_table_rehash (hash_table.c:269) ==25729== by 0x69280AC: hash_table_insert (hash_table.c:301) ==25729== by 0x6D52812: si_shader_cache_insert_shader (si_state_shaders.c:198) ==25729== by 0x6D52812: si_init_shader_selector_async (si_state_shaders.c:1353) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== ==25729== 520 bytes in 6 blocks are possibly lost in loss record 2,715 of 3,085 ==25729== at 0x402C267: malloc (vg_replace_malloc.c:299) ==25729== by 0x6D4FA9A: read_chunk (si_state_shaders.c:99) ==25729== by 0x6D524CD: si_load_shader_binary (si_state_shaders.c:165) ==25729== by 0x6D524CD: si_shader_cache_load_shader (si_state_shaders.c:216) ==25729== by 0x6D524CD: si_init_shader_selector_async (si_state_shaders.c:1336) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== ==25729== 2,304 bytes in 6 blocks are possibly lost in loss record 2,935 of 3,085 ==25729== at 0x402DDE5: calloc (vg_replace_malloc.c:711) ==25729== by 0x6D51FA6: si_init_shader_selector_async (si_state_shaders.c:1319) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== ==25729== 7,260 bytes in 6 blocks are possibly lost in loss record 3,014 of 3,085 ==25729== at 0x402C267: malloc (vg_replace_malloc.c:299) ==25729== by 0x6D4FA9A: read_chunk (si_state_shaders.c:99) ==25729== by 0x6D52514: si_load_shader_binary (si_state_shaders.c:171) ==25729== by 0x6D52514: si_shader_cache_load_shader (si_state_shaders.c:216) ==25729== by 0x6D52514: si_init_shader_selector_async (si_state_shaders.c:1336) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== ==25729== 9,668 bytes in 15 blocks are possibly lost in loss record 3,028 of 3,085 ==25729== at 0x402C267: malloc (vg_replace_malloc.c:299) ==25729== by 0x6D52001: si_get_tgsi_binary (si_state_shaders.c:50) ==25729== by 0x6D52001: si_init_shader_selector_async (si_state_shaders.c:1330) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== ==25729== 21,668 bytes in 15 blocks are possibly lost in loss record 3,061 of 3,085 ==25729== at 0x402DDE5: calloc (vg_replace_malloc.c:711) ==25729== by 0x6D52699: si_get_shader_binary (si_state_shaders.c:125) ==25729== by 0x6D52699: si_shader_cache_insert_shader (si_state_shaders.c:194) ==25729== by 0x6D52699: si_init_shader_selector_async (si_state_shaders.c:1353) ==25729== by 0x6A780B6: util_queue_thread_func (u_queue.c:154) ==25729== by 0x6A77C04: impl_thrd_routine (threads_posix.h:87) ==25729== by 0x4245249: start_thread (pthread_create.c:333) ==25729== by 0x4340D6D: clone (clone.S:114) ==25729== shows up in (at least): amstream/amstream.c d2d1/d2d1.c d3d11/d3d11.c d3d10core/device.c etc. -- 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 2