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

[Bug 47291] New: Cherry Player 2.5.6 can't play local media files
by wine-bugs＠winehq.org 28 May '20

28 May '20

https://bugs.winehq.org/show_bug.cgi?id=47291 Bug ID: 47291 Summary: Cherry Player 2.5.6 can't play local media files Product: Wine-staging Version: 4.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: oleg.dubinskij2013(a)yandex.ua CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: Ubuntu Created attachment 64589 --> https://bugs.winehq.org/attachment.cgi?id=64589 Terminal output when trying to play files via Cherry Player Cherry Player 2.5.6 does nothing after adding any local media (audio/video) files (for example, I tested it with mp4 and wav) via "Open" dialog into playlist and then trying to play them by clicking "Play" button. After clicking, it becomes "Pause" button for the moment and then restores to "Play" again. However, online streams which are inbuilt in this player, are played correctly. Download: http://download.cherryplayer.com/2.5.6/CherryPlayer-2.5.6-setup.exe sha1sum CherryPlayer-2.5.6-setup.exe cdaa69a7666072fd2a84832bd46dec81dcf5f227 CherryPlayer-2.5.6-setup.exe In the terminal, it spams about something unimplemented in quartz/vmr9 when I click "Play". Note: This program also installs Microsoft Visual C++ 2013 Redistributable x86 together with itself. -- 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.

2 3

[Bug 46132] New: Multiple Windows 10 ARM64 apps crash with illegal instruction fault due to access of ARMv8 PMU cycle counter via 'PMCCNTR_EL0' register in EL0 (Linux kernel disallows access by default)
by wine-bugs＠winehq.org 26 May '20

26 May '20

https://bugs.winehq.org/show_bug.cgi?id=46132 Bug ID: 46132 Summary: Multiple Windows 10 ARM64 apps crash with illegal instruction fault due to access of ARMv8 PMU cycle counter via 'PMCCNTR_EL0' register in EL0 (Linux kernel disallows access by default) Product: Wine Version: 3.20 Hardware: aarch64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, just for documentation ... --- snip --- $ WINEDEBUG=+seh,+loaddll,+process,+relay,+msvcrt wine64 ./gatherosstate.exe >>log.txt 2>&1 ... 0009:trace:msvcrt:DllMain finished process init 0009:Ret PE DLL (proc=0x7fae7e3b04,module=0x7fae730000 L"msvcrt.dll",reason=PROCESS_ATTACH,res=0x22fc48) retval=1 0009:Call PE DLL (proc=0x7fae5fd5d8,module=0x7fae580000 L"advapi32.dll",reason=PROCESS_ATTACH,res=0x22fc48) 0009:Ret PE DLL (proc=0x7fae5fd5d8,module=0x7fae580000 L"advapi32.dll",reason=PROCESS_ATTACH,res=0x22fc48) retval=1 0009:Starting process L"Z:\\home\\focht\\Downloads\\ARM64-win10-apps\\gatherosstate.exe" (entryproc=0x14002fd80) 0009:trace:process:NtQueryInformationProcess (0xffffffffffffffff,0x00000007,0x22f988,0x00000008,(nil)) 0009:trace:seh:call_stack_handlers calling handler at 0x7b4d6330 code=c000001d flags=0 wine: Unhandled illegal instruction at address 0x14002fc0c (thread 0009), starting debugger... 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 32" --- snip --- strace: --- snip --- 2752 [000000014002fc0c] --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x14002fc0c} --- --- snip --- Disassembly around faulting instruction: --- snip --- start: 000000014002FD80 F3 53 BE A9 STP X19, X20, [SP,#-0x20+var_s0]! 000000014002FD84 F5 0B 00 F9 STR X21, [SP,#var_s10] 000000014002FD88 FD 7B BF A9 STP X29, X30, [SP,#var_10]! 000000014002FD8C FD 03 00 91 MOV X29, SP 000000014002FD90 13 00 80 52 MOV W19, #0 000000014002FD94 9B FF FF 97 BL sub_14002FC00 000000014002FD98 F5 03 00 2A MOV W21, W0 ... sub_14002FC00: 000000014002FC00 F3 0F 1F F8 STR X19, [SP,#-0x10+var_s0]! 000000014002FC04 FD 7B BF A9 STP X29, X30, [SP,#var_10]! 000000014002FC08 FD 03 00 91 MOV X29, SP 000000014002FC0C 08 9D 3B D5 MRS X8, #3, c9, c13, #0 ; *boom* 000000014002FC10 0A 03 00 B0 ADRP X10, #qword_140090670(a)PAGE 000000014002FC14 53 C1 19 91 ADD X19, X10, #qword_140090670(a)PAGEOFF 000000014002FC18 08 79 40 92 AND X8, X8, #0x7FFFFFFF --- snip --- Decoding the sysreg using ARM's ARMv8 Processor Technical Reference Manual: MRS <Xt>, (<systemreg>|S<op0>_<op1>_<Cn>_<Cm>_<op2>) 08 9D 3B D5 -> D5 3B 9D 08 | D5 | 3B | 9D | 08 | |11010101|00 1 11 011|1001 1101|000 01000| | OPCode |L|o0|op1|CRn |CRm |op2| Rt | op0 = 3 op1 = 3 op2 = 0 CRn = 9 CRm = 13 Rt = 8 0x08,0x9d,0x3b,0xd5 = 'MRS X8, PMCCNTR_EL0' Microsoft docs: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?vi… --- quote --- Cycle counter All ARMv8 CPUs are required to support a cycle counter register. This is a 64-bit register that Windows configures to be readable at any exception level (including user mode). It can be accessed via the special PMCCNTR_EL0 register, using the MSR opcode in assembly code, or the _ReadStatusReg intrinsic in C/C++ code. Note that the cycle counter here is a true cycle counter, not a wall clock, and thus the counting frequency will vary with the processor frequency. If you feel you must know the frequency of the cycle counter, you should not be using the cycle counter. Instead, you want to measure wall clock time, for which you should use QueryPerformanceCounter. --- quote --- Defined as 'ReadTimeStampCounter()' in Windows 10 SDK header 'winnt.h'. Current QEMU for ARM64 supports it (if not run under real hardware): https://github.com/qemu/qemu/blob/master/target/arm/helper.c#L1410 --- snip --- #ifndef CONFIG_USER_ONLY ... { .name = "PMCCNTR_EL0", .state = ARM_CP_STATE_AA64, .opc0 = 3, .opc1 = 3, .crn = 9, .crm = 13, .opc2 = 0, .access = PL0_RW, .accessfn = pmreg_access_ccntr, .type = ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write, }, #endif --- snip --- The relevant piece of Linux kernel code: https://github.com/torvalds/linux/commit/60792ad349f3c6dc5735aafefe5dc9121c… --- quote --- arm64: kernel: enforce pmuserenr_el0 initialization and restore The pmuserenr_el0 register value is architecturally UNKNOWN on reset. Current kernel code resets that register value iff the core pmu device is correctly probed in the kernel. On platforms with missing DT pmu nodes (or disabled perf events in the kernel), the pmu is not probed, therefore the pmuserenr_el0 register is not reset in the kernel, which means that its value retains the reset value that is architecturally UNKNOWN (system may run with eg pmuserenr_el0 == 0x1, which means that PMU counters access is available at EL0, which must be disallowed). This patch adds code that resets pmuserenr_el0 on cold boot and restores it on core resume from shutdown, so that the pmuserenr_el0 setup is always enforced in the kernel. --- quote --- Since the Linux kernel maintainers disallow PMU counter access in EL0 by default, one has to patch the Linux kernel or use a helper kernel module. Windows 10 ARM64 likely has PMU counter access in EL0 enabled by default. There were some attempts in the past, but they never made it in. https://patchwork.kernel.org/patch/5217341/ https://github.com/zhiyisun/enable_arm_pmu/tree/dev Anyway, nothing to fix in Wine here. Upstream (if at all). Regards -- 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.

2 5

[Bug 30353] New: IEDriver from selenium crash
by wine-bugs＠winehq.org 25 May '20

25 May '20

http://bugs.winehq.org/show_bug.cgi?id=30353 Bug #: 30353 Summary: IEDriver from selenium crash Product: Wine Version: 1.5.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified 1. Download and install python26 from http://www.python.org/ftp/python/2.6/python-2.6.msi 2. Download and install easyinstall from http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11.win32-py… 3. start wine cmd, install Selenium with easyinstall : easyinstall selenium 3.5 winetricks wininet, works around Bug 30352 4. start the sample python-selenium script as attachment selenium-Ie.py : $ wine 'c:\python26\python.exe' selenium-Ie.py $ ./selenium-Ie.sh iexplore starts successfully, but then IEDriver of selenium crashes: Backtrace: =>0 0x00d045d1 in iedriver (+0x845d1) (0x0262e460) 1 0x00c9fd1a in iedriver (+0x1fd19) (0x0262e4e0) 2 0x00ca9490 in iedriver (+0x2948f) (0x0262e538) -- 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.

2 17

[Bug 24038] New: kernel32.UnhandledExceptionFilter: ensure that registered JIT debugger can attach and collect debugging info before return
by wine-bugs＠winehq.org 24 May '20

24 May '20

http://bugs.winehq.org/show_bug.cgi?id=24038 Summary: kernel32.UnhandledExceptionFilter: ensure that registered JIT debugger can attach and collect debugging info before return Product: Wine Version: 1.3.0 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, the symptom is some apps generate unhandled exceptions which ought to call the registered just-in-time debugger but the collection of debugging info fails. When the debugger process is up and running the faulting app is gone, hence attaching and collecting module, backtrace info etc. fails. Example (you can find several of such occurrences in bugzilla): --- snip --- ... wine: Unhandled exception 0xc000000d at address 0x68080023:0x004bd342 (thread 0026), starting debugger... 0026:trace:seh:start_debugger Starting debugger "winedbg --auto 37 252" 0027:Ret KERNEL32.Sleep() retval=00000000 ret=00484091 0027:Call KERNEL32.Sleep(00000032) ret=00484091 0028:Ret KERNEL32.Sleep() retval=00000000 ret=00484091 0028:Call KERNEL32.Sleep(00000032) ret=00484091 0026:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=004c599a 0026:Call KERNEL32.GetCurrentProcess() ret=004c59b5 0026:Ret KERNEL32.GetCurrentProcess() retval=ffffffff ret=004c59b5 0026:Call KERNEL32.TerminateProcess(ffffffff,c000000d) ret=004c59bc Process of pid=0025 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded No process loaded, cannot execute 'echo Threads:' process tid prio (all id:s are in hex) --- snip --- kernel32.UnhandledExceptionFilter() -> start_debugger_atomic -> start_debugger -> CreateProcessA() (wait for debugger to come up) -> return The app code immediately terminates the process after return from UnhandledExceptionFilter() which is an indication that all debugging info collection stuff needs to be done synchronously _before_ UnhandledExceptionFilter() returns in case JIT debugger was called. 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.

2 13

[Bug 44915] New: Metal Gear Solid V: The Phantom Pain - SP crashes silently
by wine-bugs＠winehq.org 22 May '20

22 May '20

https://bugs.winehq.org/show_bug.cgi?id=44915 Bug ID: 44915 Summary: Metal Gear Solid V: The Phantom Pain - SP crashes silently Product: Wine Version: 3.5 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: romulasry(a)gmail.com Distribution: --- Created attachment 61002 --> https://bugs.winehq.org/attachment.cgi?id=61002 logfile It silently exits or doesn't launch, I don't know which one. -- 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.

2 4

[Bug 15489] New: Build should optionally produce .pdb file suitable for use with symbol server
by wine-bugs＠winehq.org 22 May '20

22 May '20

http://bugs.winehq.org/show_bug.cgi?id=15489 Summary: Build should optionally produce .pdb file suitable for use with symbol server Product: Wine Version: 1.1.5 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: build-env AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com When Windows applications with their own crash logging systems crash, they report the stack dump to their own crash dump server, which uses Microsoft-supplied .pdb files (or Microsoft's symbol server) to resolve the symbol names in system DLLs. Wine should also provide such .pdb files, for use by vendors in analyzing crash dumps. There should be an identifying key in the crash dump and the .pdb file allowing the crash server or debugger to choose the proper .pdb file; MSFT must support that, let's see if we can use the same mechanism they do to handle the much larger number of Wine versions and flavors. -- 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.

2 7

[Bug 43962] New: msvcrt/string tests fail
by wine-bugs＠winehq.org 22 May '20

22 May '20

https://bugs.winehq.org/show_bug.cgi?id=43962 Bug ID: 43962 Summary: msvcrt/string tests fail Product: Wine Version: 2.20 Hardware: x86 OS: Linux Status: NEW Keywords: download, testcase Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Debian string.c:2799: Test failed: errno = -559038737 string.c:2809: Test failed: ret = d0 string.c:1878: Test failed: d = 1000000000000000482416141386308708571867933472627945326741491900144172904106310050588962644037102476595408159456210748972770600252972845262058045244417464426905986489749230528825980973749133650163621397243851020732242333839884529407361024.000000 string.c:2710: Test failed: ret = ffffff81 string.c:2713: Test failed: ret = ffffff9f string.c:2716: Test failed: ret = ffffffe0 string.c:2877: Test failed: d.x = 0.000000e+000, expected 0 string.c:2880: Test failed: d.x = 0.000000e+000, expected 0 there's a lot of: fixme:msvcrt:_control87 not implemented fixme:msvcrt:_control87 not implemented -- 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.

2 10

[Bug 29168] New: Star Wars: The Old Republic game client hangs at
by wine-bugs＠winehq.org 22 May '20

22 May '20

http://bugs.winehq.org/show_bug.cgi?id=29168 Bug #: 29168 Summary: Star Wars: The Old Republic game client hangs at Product: Wine Version: 1.3.33 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: erik.weatherwax(a)gmail.com Classification: Unclassified Created attachment 37628 --> http://bugs.winehq.org/attachment.cgi?id=37628 Console output Upon successful launching of the game client after logging in via the game launcher, no progress is made towards loading the game after the initial splash screen: it merely sits at the initial splash with a sort of "Working" icon spinning in the lower right indefinitely. Console output is attached but doesn't seem to be much help; it is mostly just spam of: fixme:win:GetWindowPlacement not supported on other process window 0xa0026 fixme:d3d:query_init Unhandled query type 0xc. Originally suspected this was a server-side or game client problem since some Windows users were reporting similar issues at the beginning of this beta test weekend; however, any of numerous purported workarounds fail to work in Wine, and it seems the problem pretty uniformly affects Wine users, at least in Linux. -- 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.

2 371

[Bug 43959] New: webservices/reader tests fail on arm
by wine-bugs＠winehq.org 22 May '20

22 May '20

https://bugs.winehq.org/show_bug.cgi?id=43959 Bug ID: 43959 Summary: webservices/reader tests fail on arm Product: Wine Version: 2.19 Hardware: arm OS: Linux Status: NEW Keywords: download, testcase Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Debian fixme:webservices:set_fpword not implemented reader.c:3733: Test failed: 0: got 80004001 fixme:webservices:set_fpword not implemented reader.c:3733: Test failed: 1: got 80004001 fixme:webservices:set_fpword not implemented reader.c:3733: Test failed: 2: got 80004001 Pretty obvious why: https://source.winehq.org/git/wine.git/blob/039d267b0925273197a9edcf7664c4a… 3599 BOOL set_fpword( unsigned short new, unsigned short *old ) 3600 { 3601 #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) 3602 unsigned short fpword; 3603 3604 __asm__ __volatile__( "fstcw %0" : "=m" (fpword) ); 3605 *old = fpword; 3606 fpword = new; 3607 __asm__ __volatile__( "fldcw %0" : : "m" (fpword) ); 3608 return TRUE; 3609 #else 3610 FIXME( "not implemented\n" ); 3611 return FALSE; 3612 #endif 3613 } -- 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.

2 12

[Bug 43960] New: rpcrt4/cstub tests fail on arm
by wine-bugs＠winehq.org 22 May '20

22 May '20

https://bugs.winehq.org/show_bug.cgi?id=43960 Bug ID: 43960 Summary: rpcrt4/cstub tests fail on arm Product: Wine Version: 2.19 Hardware: arm OS: Linux Status: NEW Keywords: download, testcase Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Debian (stretch)austin(a)localhost:~/wine-git/dlls/rpcrt4/tests$ make test ../../../tools/runtest -q -P wine -T ../../.. -M rpcrt4.dll -p rpcrt4_test.exe.so cstub && touch cstub.ok cstub.c:1123: Test failed: ret c0000005 Makefile:185: recipe for target 'cstub.ok' failed make: *** [cstub.ok] Error 1 -- 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.

2 4