March 2019 - Wine-bugs - list.winehq.org

[Bug 46809] New: PS4 Remote Play doesn't open
by wine-bugs＠winehq.org 10 Jun '19

10 Jun '19

https://bugs.winehq.org/show_bug.cgi?id=46809 Bug ID: 46809 Summary: PS4 Remote Play doesn't open Product: Wine Version: 4.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: throwawayaccx(a)gmail.com Distribution: --- Created attachment 63832 --> https://bugs.winehq.org/attachment.cgi?id=63832 Log of opening app PS4 Remote Play never opens and spits out a backtrace. -- 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 10 Jun '19

10 Jun '19

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 10 Jun '19

10 Jun '19

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 10 Jun '19

10 Jun '19

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 10 Jun '19

10 Jun '19

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 10 Jun '19

10 Jun '19

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 10 Jun '19

10 Jun '19

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

[Bug 36652] New: valgrind shows some uninitialized variables in d3d10core/tests/device.c
by wine-bugs＠winehq.org 10 Jun '19

10 Jun '19

https://bugs.winehq.org/show_bug.cgi?id=36652 Bug ID: 36652 Summary: valgrind shows some uninitialized variables in d3d10core/tests/device.c Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==6205== Conditional jump or move depends on uninitialised value(s) ==6205== at 0x402DEDF: bcmp (mc_replace_strmem.c:935) ==6205== by 0x50CE81F: d3d10_depthstencil_state_compare (device.c:2092) ==6205== by 0x50C7637: wine_rb_get (rbtree.h:237) ==6205== by 0x50CCA1A: d3d10_device_CreateDepthStencilState (device.c:1416) ==6205== by 0x4F5C5AD: test_create_depthstencil_state (d3d10.h:5752) ==6205== by 0x4F5D127: func_device (device.c:893) ==6205== by 0x4F5DF24: run_test (test.h:584) ==6205== by 0x4F5E312: main (test.h:654) ==6205== Uninitialised value was created by a stack allocation ==6205== at 0x4F5C3D1: test_create_depthstencil_state (device.c:728) ==6205== } ==6205== Conditional jump or move depends on uninitialised value(s) ==6205== at 0x402DEDF: bcmp (mc_replace_strmem.c:935) ==6205== by 0x50CE81F: d3d10_depthstencil_state_compare (device.c:2092) ==6205== by 0x50D1E68: wine_rb_remove (rbtree.h:291) ==6205== by 0x50D2BA5: d3d10_depthstencil_state_Release (state.c:222) ==6205== by 0x4F5C7CE: test_create_depthstencil_state (d3d10.h:3052) ==6205== by 0x4F5D127: func_device (device.c:893) ==6205== by 0x4F5DF24: run_test (test.h:584) ==6205== by 0x4F5E312: main (test.h:654) ==6205== Uninitialised value was created by a stack allocation ==6205== at 0x4F5C3D1: test_create_depthstencil_state (device.c:728) ==6205== ==6205== Conditional jump or move depends on uninitialised value(s) ==6205== at 0x402DEDF: bcmp (mc_replace_strmem.c:935) ==6205== by 0x50CE81F: d3d10_depthstencil_state_compare (device.c:2092) ==6205== by 0x50D1EF8: wine_rb_remove (rbtree.h:300) ==6205== by 0x50D2BA5: d3d10_depthstencil_state_Release (state.c:222) ==6205== by 0x4F5C7CE: test_create_depthstencil_state (d3d10.h:3052) ==6205== by 0x4F5D127: func_device (device.c:893) ==6205== by 0x4F5DF24: run_test (test.h:584) ==6205== by 0x4F5E312: main (test.h:654) ==6205== Uninitialised value was created by a stack allocation ==6205== at 0x4F5C3D1: test_create_depthstencil_state (device.c:728) ==6205== This is on nvidia hardware, rather than intel/mesa: OpenGL renderer string: GeForce GTX 460/PCIe/SSE2 OpenGL core profile version string: 4.3.0 NVIDIA 337.25 -- 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 36249] New: valgrind shows two potential leaks in d3d10/tests/effect.c
by wine-bugs＠winehq.org 10 Jun '19

10 Jun '19

https://bugs.winehq.org/show_bug.cgi?id=36249 Bug ID: 36249 Summary: valgrind shows two potential leaks in d3d10/tests/effect.c Product: Wine Version: 1.7.18 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==25807== 12,068 bytes in 1 blocks are possibly lost in loss record 779 of 802 ==25807== at 0x7BC4C735: notify_alloc (heap.c:255) ==25807== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==25807== by 0x4D9230A: wined3d_create (wined3d_main.c:95) ==25807== by 0x4C621D6: dxgi_factory_init (factory.c:332) ==25807== by 0x4C62568: dxgi_factory_create (factory.c:404) ==25807== by 0x4C6084A: CreateDXGIFactory (dxgi_main.c:80) ==25807== by 0x49B63B8: D3D10CreateDevice (d3d10_main.c:63) ==25807== by 0x495611C: create_device (effect.c:30) ==25807== by 0x4967153: test_effect_local_shader (effect.c:2723) ==25807== by 0x497315C: func_effect (effect.c:4284) ==25807== by 0x4973F60: run_test (test.h:584) ==25807== by 0x497434F: main (test.h:654) ==28927== 12,068 bytes in 1 blocks are possibly lost in loss record 808 of 833 ==28927== at 0x7BC4C735: notify_alloc (heap.c:255) ==28927== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==28927== by 0x4F8213E: wined3d_create (wined3d_main.c:95) ==28927== by 0x4E521D6: dxgi_factory_init (factory.c:332) ==28927== by 0x4E52568: dxgi_factory_create (factory.c:404) ==28927== by 0x4E5084A: CreateDXGIFactory (dxgi_main.c:80) ==28927== by 0x49B63B8: D3D10CreateDevice (d3d10_main.c:63) ==28927== by 0x495611C: create_device (effect.c:30) ==28927== by 0x496FEC9: test_effect_state_groups (effect.c:3908) ==28927== by 0x4973166: func_effect (effect.c:4286) ==28927== by 0x4973F60: run_test (test.h:584) ==28927== by 0x497434F: main (test.h:654) ==28927== -- 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 46518] New: Samurai Warriors 4 II crash at begins
by wine-bugs＠winehq.org 08 Jun '19

08 Jun '19

https://bugs.winehq.org/show_bug.cgi?id=46518 Bug ID: 46518 Summary: Samurai Warriors 4 II crash at begins Product: Wine Version: 4.0 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: mrdeathjr28(a)yahoo.es Distribution: --- This game crash at begins and shows interesting text (in catherine classic shows similar error too) 4 0x7b46592e start_process+0x1bd(entry=<couldn't compute location>, peb=<couldn't compute location>) [/home/linuxdesktopx86/Documentos/Respaldo/Instaladores/Wine-Test/wine-4.1b/dlls/kernel32/process.c:1273] in kernel32 And line 1273 stay related with this: /*********************************************************************** * start_process * * Startup routine of a new process. Runs on the new process stack. */ void WINAPI start_process( LPTHREAD_START_ROUTINE entry, PEB *peb ) { BOOL being_debugged; if (!entry) { ERR( "%s doesn't have an entry point, it cannot be executed\n", debugstr_w(peb->ProcessParameters->ImagePathName.Buffer) ); ExitThread( 1 ); } TRACE_(relay)( "\1Starting process %s (entryproc=%p)\n", debugstr_w(peb->ProcessParameters->ImagePathName.Buffer), entry ); __TRY { if (!CheckRemoteDebuggerPresent( GetCurrentProcess(), &being_debugged )) being_debugged = FALSE; SetLastError( 0 ); /* clear error code */ if (being_debugged) DbgBreakPoint(); ExitThread( call_process_entry( peb, entry )); } __EXCEPT(UnhandledExceptionFilter) { TerminateThread( GetCurrentThread(), GetExceptionCode() ); } __ENDTRY abort(); /* should not be reached */ -- 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 3