[Webkit-unassigned] [Bug 223476] New: [iOS 14.5 beta] Crash in call to logger() in UserMediaPermissionRequestManagerProxy::computeFilteredDeviceList
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Mar 18 13:45:40 PDT 2021
https://bugs.webkit.org/show_bug.cgi?id=223476
Bug ID: 223476
Summary: [iOS 14.5 beta] Crash in call to logger() in
UserMediaPermissionRequestManagerProxy::computeFiltere
dDeviceList
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Media
Assignee: webkit-unassigned at lists.webkit.org
Reporter: ajuma at chromium.org
CC: cdumez at apple.com, jer.noble at apple.com,
youennf at gmail.com
Chrome for iOS is getting reports of a crash that's new in iOS 14.5 beta (first seen in beta 2) with the following stack:
CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x00000020 ]
Stack Quality84%Show frame trust levels
0x0000000196b2debc (WebKit + 0x00367ebc) WebKit::WebPageProxy::logger()
0x0000000196b2de70 (WebKit + 0x00367e70) WebKit::WebPageProxy::logger()
0x0000000196aee014 (WebKit + 0x00328014) WTF::Detail::CallableWrapper<WebKit::UserMediaPermissionRequestManagerProxy::computeFilteredDeviceList(bool, WTF::CompletionHandler<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&)::$_12, void, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&>::call(WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)
0x00000001988ff584 (WebCore + 0x00000000019ae584) WTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::getMediaStreamDevices(WTF::CompletionHandler<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&)::$_25, void, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&>::call(WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)
0x00000001988fba10 (WebCore + 0x00000000019aaa10) WTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::getMediaStreamDevices(WTF::CompletionHandler<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&)::CaptureDeviceAccumulator::accumulate()::'lambda'(WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&), void, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&>::~CallableWrapper()
0x0000000196f810d0 (WebCore + 0x000300d0) WTF::BlockPtr<void ()> WTF::BlockPtr<void ()>::fromCallable<WebCore::AVAudioSessionCaptureDeviceManager::getCaptureDevices(WTF::CompletionHandler<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&)::$_5::operator()()::'lambda'()>(WebCore::AVAudioSessionCaptureDeviceManager::getCaptureDevices(WTF::CompletionHandler<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&)::$_5::operator()()::'lambda'())::'lambda'(void*)::__invoke(void*)
0x000000018a50f2ac (libdispatch.dylib + 0x000602ac) _dispatch_call_block_and_release
0x000000018a510294 (libdispatch.dylib + 0x00061294) _dispatch_client_callout
0x000000018a4f2484 (libdispatch.dylib + 0x00043484) _dispatch_main_queue_callback_4CF$VARIANT$armv81
0x000000018a857560 (CoreFoundation + 0x0009a560) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
0x000000018a8519c0 (CoreFoundation + 0x000949c0) __CFRunLoopRun
0x000000018a850a98 (CoreFoundation + 0x00093a98) CFRunLoopRunSpecific
0x00000001a14a256c (GraphicsServices + 0x0000356c) GSEventRunModal
0x000000018d16cc2c (UIKitCore + 0x00b2ec2c) -[UIApplication _run]
0x000000018d1721a8 (UIKitCore + 0x00b341a8) UIApplicationMain
0x0000000100a124ec (Chrome -chrome_exe_main.mm:71) main
0x000000018a52f13c (libdyld.dylib + 0x0000113c) start
It looks like the call to ALWAYS_LOG in UserMediaPermissionRequestManagerProxy::computeFilteredDeviceList is crashing because m_page is null (and hence the call to logger() crashes).
Looking at the code, I don't see how this can be null though.
The most recent code change in this area seems to be from bug 220471, in January.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210318/54f7cf64/attachment-0001.htm>
More information about the webkit-unassigned
mailing list