https://bugs.winehq.org/show_bug.cgi?id=57116
Bug ID: 57116 Summary: Crash during codecs test on CEF sample application Product: Wine Version: 9.16 Hardware: x86-64 URL: https://cef-builds.spotifycdn.com/cef_binary_127.3.5%2 Bg114ea2a%2Bchromium-127.0.6533.120_windows64_client.t ar.bz2 OS: Linux Status: NEW Keywords: download, source Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: imwellcushtymelike@gmail.com Distribution: Ubuntu
Created attachment 77008 --> https://bugs.winehq.org/attachment.cgi?id=77008 Wine 9.16 console output
Running the Codecs test on the Chromium Embedded Framework sample application causes a crash, but winedbg is unable to provide any further details (also the OK button from winedbg doesn't work).
The application itself does not close and continues to run.
Run with: wine cefclient.exe --url=https://shaka-player-demo.appspot.com/support.html
https://bugs.winehq.org/show_bug.cgi?id=57116
--- Comment #1 from Ken Sharp imwellcushtymelike@gmail.com --- Same thing in Staging 9.16 but the OK button works on winedbg.
https://bugs.winehq.org/show_bug.cgi?id=57116
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Crash during codecs test on |Crash during codecs test on |CEF sample application |64-bit CEF sample | |application Keywords| |win64
--- Comment #2 from Ken Sharp imwellcushtymelike@gmail.com --- The crash does not occur with the 32-bit CEF sample application.
https://bugs.winehq.org/show_bug.cgi?id=57116
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Crash during codecs test on |Crash during codecs test on |64-bit CEF sample |CEF sample application in |application |64-bit wineprefix | |(widevinecdm)
--- Comment #3 from Ken Sharp imwellcushtymelike@gmail.com --- However, the crash does occur with the 32-bit application if running in a 64-bit wineprefix.
I imagine there's an easier way to trigger the crash but I don't know what that is at the moment.
winedbg behaves differently again: no dialog is produced at all.
0318:trace:loaddll:free_modref Unloaded module L"C:\users\test\AppData\Local\CEF\User Data\WidevineCdm\4.10.2710.0\_platform_specific\win_x86\widevinecdm.dll" : native 0320:trace:loaddll:build_module Loaded L"C:\windows\system32\opengl32.dll" at 66480000: builtin 0320:trace:loaddll:build_module Loaded L"C:\windows\system32\wined3d.dll" at 669A0000: builtin 0320:trace:loaddll:build_module Loaded L"C:\windows\system32\dxgi.dll" at 67C20000: builtin 0318:trace:loaddll:build_module Loaded L"C:\users\test\AppData\Local\CEF\User Data\WidevineCdm\4.10.2710.0\_platform_specific\win_x86\widevinecdm.dll" at 67D50000: native 0318:trace:loaddll:free_modref Unloaded module L"C:\users\test\AppData\Local\CEF\User Data\WidevineCdm\4.10.2710.0\_platform_specific\win_x86\widevinecdm.dll" : native 0318:fixme:ntdll:NtSetInformationToken TokenIntegrityLevel stub! 0318:fixme:process:NtQueryInformationProcess ProcessHandleCount (0xffffffff,0x20defc4,0x00000004,(nil)) stub 0318:fixme:process:NtQueryInformationProcess ProcessHandleTable (0xffffffff,0x20aec000,0x00000fa0,0x20defb4) stub 0318:fixme:process:SetProcessMitigationPolicy (8, 020DEFB8, 4): stub wine: Unhandled page fault on execute access to 682F3000 at address 682F3000 (thread 0318), starting debugger...
By disabling widevinecdm.dll the crash does not occur.
https://bugs.winehq.org/show_bug.cgi?id=57116
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 77146 --> https://bugs.winehq.org/attachment.cgi?id=77146 backtrace one instruction before jumping to not mapped memory
I was able to get into this process one instruction before it calls into currently not mapped memory, which generates the final "Unhandled page fault on execute access".
The backtrace looks like this: (gdb) bt #0 RtlProcessFlsData(teb_fls_data=0x7ffffe9386b0,flags=1) at ntdll/thread.c:714 #1 LdrShutdownProcess() at include/winnt.h:2505 #2 RtlExitUserProcess(status=0) at ntdll/loader.c:3887 #3 ExitProcess(status=3831291664) at kernel32/process.c:207 #4 cefclient!GetHandleVerifier() from cefclient.exe
With the current instruction and register RSI value: 1: x/i $pc => 0x6fffffc9ca10 <RtlProcessFlsData+344>: call *%rsi 2: /x $rsi = 0x6fffe3a77580
The reason why winedbg could no longer attach could be, because the process shutdown is already too far?
The +seh,+module log looks also like the process tried to load widevinecdm.dll twice. There happened already an "access violation on write" before, this could be the reason the Dll gets unloaded again. Unfortunately it had already entered some callbacks to the "Fiber Local Storage", which get still executed RtlProcessFlsData, even when the Dll is no longer loaded.
The first "access violation on write" shows up here: 0x00006fffe3a92702 in widevinecdm!VerifyCdmHost_0() from widevinecdm.dll
-
WineHQ Bugzilla