Bug 1631803 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

bp-4e65a755-f848-44ee-bf70-c9c3d0221005 seems to have a useful stack:
```
Crashing Thread (95), Name: VideoCapture
Frame 	Module 	Signature 	Source 	Trust
0 	XUL 	CrashReporter::TerminateHandler() 	toolkit/crashreporter/nsExceptionHandler.cpp:1838 	context
1 	libc++abi.dylib 	std::__terminate(void (*)()) 		cfi
2 	libc++abi.dylib 	std::terminate() 		cfi
3 	libobjc.A.dylib 	objc_terminate 		cfi
4 	libdispatch.dylib 	_dispatch_client_callout 		cfi
5 	libdispatch.dylib 	_dispatch_once_callout 		cfi
Ø 6 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000cb20 		cfi
Ø 7 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000f4c0 		frame_pointer
8 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreatePlugIn(CMIO::DAL::CFPlugIn const*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*) 		frame_pointer
9 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreateOrLazyLoadPlugIns(std::__1::vector<CMIO::DAL::CFPlugIn*, std::__1::allocator<CMIO::DAL::CFPlugIn*> >*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*, std::__1::vector<CMIO::DAL::PlugInManagement::MatchingInfo*, std::__1::allocator<CMIO::DAL::PlugInManagement::MatchingInfo*> >*, void (*)(void*, unsigned int)) 		cfi
10 	CoreMediaIO 	CMIO::DAL::PlugInManagement::Initialize() 		cfi
11 	CoreMediaIO 	CMIO::DAL::System::InitializeDevices() 		cfi
12 	CoreMediaIO 	CMIO::DAL::System::CheckOutInstance() 		cfi
13 	CoreMediaIO 	CMIOObjectGetPropertyDataSize 		cfi
14 	AVFCapture 	+[AVCaptureDALDevice _refreshDevices] 		cfi
15 	AVFCapture 	__39+[AVCaptureDALDevice _ensureDeviceList]_block_invoke 		cfi
16 	libdispatch.dylib 	_dispatch_client_callout 		cfi
17 	libdispatch.dylib 	_dispatch_once_callout 		cfi
18 	AVFCapture 	+[AVCaptureDALDevice devices] 		cfi
19 	AVFCapture 	+[AVCaptureDevice_Tundra _devicesWithAllowIOSMacEnvironment:] 		cfi
20 	AVFCapture 	+[AVCaptureDevice_Tundra devicesWithMediaType:] 		cfi
21 	XUL 	+[DeviceInfoIosObjC captureDeviceCount] 	dom/media/systemservices/objc_video_capture/device_info_objc.mm:45 	cfi
22 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::Init() 	dom/media/systemservices/objc_video_capture/device_info.mm:46 	cfi
23 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	cfi
24 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	inlined
24 	XUL 	webrtc::videocapturemodule::VideoCaptureImpl::CreateDeviceInfo() 	dom/media/systemservices/objc_video_capture/device_info.mm:35 	cfi
25 	XUL 	mozilla::camera::VideoEngine::GetOrCreateVideoCaptureDeviceInfo() 	dom/media/systemservices/VideoEngine.cpp:184 	cfi
26 	XUL 	mozilla::camera::CamerasParent::SetupEngine(mozilla::camera::CaptureEngine) 	dom/media/systemservices/CamerasParent.cpp:358 	cfi
27 	XUL 	mozilla::camera::CamerasParent::EnsureInitialized(int) 	dom/media/systemservices/CamerasParent.cpp:416 	cfi
28 	XUL 	mozilla::camera::CamerasParent::RecvEnsureInitialized(mozilla::camera::CaptureEngine const&)::$_4::operator()() const 	dom/media/systemservices/CamerasParent.cpp:470
```
Line 21 in that stack seems to implicate [this code](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#44-50) added in bug 1629984, which enumerates devices early, though these crashes seem to predate this code, so it may just be the unlucky code that happens to touch devices first.

I'm marking it as a regression anyway since its stack is involved now, and bug 1629984, even if it's not to blame, gives me an idea for a potential fix: what if we add a `try`/`catch` around each device [in that for-loop](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#45-46) and treated any exception-throwing device as we treat `isSuspended`?

Paul, WDYT? Or is CamTwist a lost cause? We could also dup this to bug 1451394 I suppose though we don't have any that would help any.
bp-4e65a755-f848-44ee-bf70-c9c3d0221005 seems to have a useful stack:
```
Crashing Thread (95), Name: VideoCapture
Frame 	Module 	Signature 	Source 	Trust
0 	XUL 	CrashReporter::TerminateHandler() 	toolkit/crashreporter/nsExceptionHandler.cpp:1838 	context
1 	libc++abi.dylib 	std::__terminate(void (*)()) 		cfi
2 	libc++abi.dylib 	std::terminate() 		cfi
3 	libobjc.A.dylib 	objc_terminate 		cfi
4 	libdispatch.dylib 	_dispatch_client_callout 		cfi
5 	libdispatch.dylib 	_dispatch_once_callout 		cfi
Ø 6 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000cb20 		cfi
Ø 7 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000f4c0 		frame_pointer
8 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreatePlugIn(CMIO::DAL::CFPlugIn const*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*) 		frame_pointer
9 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreateOrLazyLoadPlugIns(std::__1::vector<CMIO::DAL::CFPlugIn*, std::__1::allocator<CMIO::DAL::CFPlugIn*> >*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*, std::__1::vector<CMIO::DAL::PlugInManagement::MatchingInfo*, std::__1::allocator<CMIO::DAL::PlugInManagement::MatchingInfo*> >*, void (*)(void*, unsigned int)) 		cfi
10 	CoreMediaIO 	CMIO::DAL::PlugInManagement::Initialize() 		cfi
11 	CoreMediaIO 	CMIO::DAL::System::InitializeDevices() 		cfi
12 	CoreMediaIO 	CMIO::DAL::System::CheckOutInstance() 		cfi
13 	CoreMediaIO 	CMIOObjectGetPropertyDataSize 		cfi
14 	AVFCapture 	+[AVCaptureDALDevice _refreshDevices] 		cfi
15 	AVFCapture 	__39+[AVCaptureDALDevice _ensureDeviceList]_block_invoke 		cfi
16 	libdispatch.dylib 	_dispatch_client_callout 		cfi
17 	libdispatch.dylib 	_dispatch_once_callout 		cfi
18 	AVFCapture 	+[AVCaptureDALDevice devices] 		cfi
19 	AVFCapture 	+[AVCaptureDevice_Tundra _devicesWithAllowIOSMacEnvironment:] 		cfi
20 	AVFCapture 	+[AVCaptureDevice_Tundra devicesWithMediaType:] 		cfi
21 	XUL 	+[DeviceInfoIosObjC captureDeviceCount] 	dom/media/systemservices/objc_video_capture/device_info_objc.mm:45 	cfi
22 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::Init() 	dom/media/systemservices/objc_video_capture/device_info.mm:46 	cfi
23 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	cfi
24 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	inlined
24 	XUL 	webrtc::videocapturemodule::VideoCaptureImpl::CreateDeviceInfo() 	dom/media/systemservices/objc_video_capture/device_info.mm:35 	cfi
25 	XUL 	mozilla::camera::VideoEngine::GetOrCreateVideoCaptureDeviceInfo() 	dom/media/systemservices/VideoEngine.cpp:184 	cfi
26 	XUL 	mozilla::camera::CamerasParent::SetupEngine(mozilla::camera::CaptureEngine) 	dom/media/systemservices/CamerasParent.cpp:358 	cfi
27 	XUL 	mozilla::camera::CamerasParent::EnsureInitialized(int) 	dom/media/systemservices/CamerasParent.cpp:416 	cfi
28 	XUL 	mozilla::camera::CamerasParent::RecvEnsureInitialized(mozilla::camera::CaptureEngine const&)::$_4::operator()() const 	dom/media/systemservices/CamerasParent.cpp:470
```
Line 21 in that stack seems to implicate [this code](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#44-50) added in bug 1629984, which enumerates devices early, though these crashes seem to predate this code, so it may just be the unlucky code that happens to touch devices first now.

I'm marking it as a regression anyway since its stack is involved now, and bug 1629984, even if it's not to blame, gives me an idea for a potential fix: what if we add a `try`/`catch` around each device [in that for-loop](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#45-46) and treated any exception-throwing device as we treat `isSuspended`?

Paul, WDYT? Or is CamTwist a lost cause? We could also dup this to bug 1451394 I suppose though we don't have any that would help any.
bp-4e65a755-f848-44ee-bf70-c9c3d0221005 seems to have a useful stack:
```
Crashing Thread (95), Name: VideoCapture
Frame 	Module 	Signature 	Source 	Trust
0 	XUL 	CrashReporter::TerminateHandler() 	toolkit/crashreporter/nsExceptionHandler.cpp:1838 	context
1 	libc++abi.dylib 	std::__terminate(void (*)()) 		cfi
2 	libc++abi.dylib 	std::terminate() 		cfi
3 	libobjc.A.dylib 	objc_terminate 		cfi
4 	libdispatch.dylib 	_dispatch_client_callout 		cfi
5 	libdispatch.dylib 	_dispatch_once_callout 		cfi
Ø 6 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000cb20 		cfi
Ø 7 	exceedshare-mac-virtualcam 	exceedshare-mac-virtualcam@0x000000000000f4c0 		frame_pointer
8 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreatePlugIn(CMIO::DAL::CFPlugIn const*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*) 		frame_pointer
9 	CoreMediaIO 	CMIO::DAL::PlugInManagement::CreateOrLazyLoadPlugIns(std::__1::vector<CMIO::DAL::CFPlugIn*, std::__1::allocator<CMIO::DAL::CFPlugIn*> >*, std::__1::vector<CMIO::DAL::PlugIn*, std::__1::allocator<CMIO::DAL::PlugIn*> >*, std::__1::vector<CMIO::DAL::PlugInManagement::MatchingInfo*, std::__1::allocator<CMIO::DAL::PlugInManagement::MatchingInfo*> >*, void (*)(void*, unsigned int)) 		cfi
10 	CoreMediaIO 	CMIO::DAL::PlugInManagement::Initialize() 		cfi
11 	CoreMediaIO 	CMIO::DAL::System::InitializeDevices() 		cfi
12 	CoreMediaIO 	CMIO::DAL::System::CheckOutInstance() 		cfi
13 	CoreMediaIO 	CMIOObjectGetPropertyDataSize 		cfi
14 	AVFCapture 	+[AVCaptureDALDevice _refreshDevices] 		cfi
15 	AVFCapture 	__39+[AVCaptureDALDevice _ensureDeviceList]_block_invoke 		cfi
16 	libdispatch.dylib 	_dispatch_client_callout 		cfi
17 	libdispatch.dylib 	_dispatch_once_callout 		cfi
18 	AVFCapture 	+[AVCaptureDALDevice devices] 		cfi
19 	AVFCapture 	+[AVCaptureDevice_Tundra _devicesWithAllowIOSMacEnvironment:] 		cfi
20 	AVFCapture 	+[AVCaptureDevice_Tundra devicesWithMediaType:] 		cfi
21 	XUL 	+[DeviceInfoIosObjC captureDeviceCount] 	dom/media/systemservices/objc_video_capture/device_info_objc.mm:45 	cfi
22 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::Init() 	dom/media/systemservices/objc_video_capture/device_info.mm:46 	cfi
23 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	cfi
24 	XUL 	webrtc::videocapturemodule::DeviceInfoIos::DeviceInfoIos() 	dom/media/systemservices/objc_video_capture/device_info.mm:37 	inlined
24 	XUL 	webrtc::videocapturemodule::VideoCaptureImpl::CreateDeviceInfo() 	dom/media/systemservices/objc_video_capture/device_info.mm:35 	cfi
25 	XUL 	mozilla::camera::VideoEngine::GetOrCreateVideoCaptureDeviceInfo() 	dom/media/systemservices/VideoEngine.cpp:184 	cfi
26 	XUL 	mozilla::camera::CamerasParent::SetupEngine(mozilla::camera::CaptureEngine) 	dom/media/systemservices/CamerasParent.cpp:358 	cfi
27 	XUL 	mozilla::camera::CamerasParent::EnsureInitialized(int) 	dom/media/systemservices/CamerasParent.cpp:416 	cfi
28 	XUL 	mozilla::camera::CamerasParent::RecvEnsureInitialized(mozilla::camera::CaptureEngine const&)::$_4::operator()() const 	dom/media/systemservices/CamerasParent.cpp:470
```
Line 21 in that stack seems to implicate [this code](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#44-50) added in bug 1629984, which enumerates devices early, though these crashes seem to predate this code, so it may just be the unlucky code that happens to touch devices first now.

I'm marking it as a regression anyway since its stack is involved now, and bug 1629984, even if it's not to blame, gives me an idea for a potential fix: what if we add a `try`/`catch` around each device [in that for-loop](https://searchfox.org/mozilla-central/rev/d0f5bc50aff3462c9d1546b88d60c5cb020eb15c/dom/media/systemservices/objc_video_capture/device_info_objc.mm#45-46) and treated any exception-throwing device as we treat `isSuspended`?

Paul, WDYT? Or is CamTwist a lost cause? We could also dup this to bug 1451394 I suppose though we don't know if that would help any.

Back to Bug 1631803 Comment 13