STRs: 1. The background here is that on my new MBP since a while now, OSX messes up my camera sometimes, seems like if I close the lid while the camera is in use, then after I open it again, Firefox enumerates the camera and lets me select it, but fails immediately after choosing it, with NotReadableError: Failed to allocate videosource The camera is not available in other apps either in this situation, e.g. Photo Booth. I have to get into this situation to reproduce. The regression is that Firefox now crashes in this situation instead of reporting the above error. 2. Share the camera with any web page, e.g. https://jsfiddle.net/jib1/srn9db4h/ Expected result: - NotReadableError: Failed to allocate videosource Actual result: - https://crash-stats.mozilla.com/report/index/a1c76ea3-ca39-4f0d-88e2-626910170706 Regression range: 12:00.22 INFO: Last good revision: 7455c74d833a9db4e02be17eda14588c7ef0de76 12:00.22 INFO: First bad revision: 3b468193c933806339fa4a8dee73d03a09e635ab 12:00.22 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7455c74d833a9db4e02be17eda14588c7ef0de76&tochange=3b468193c933806339fa4a8dee73d03a09e635ab I suspect bug 1374938. UAF: ted tells me that for EXC_BAD_ACCESS / EXC_I386_GPFLT the reported crash address of 0x0 isn't reliable. A look in the Raw dump tab in the crash stats link shows a poison pattern in the rax register, which suggests a Use After Free: "registers": { "r10": "0x0000000000001008", "r11": "0x0000000132c00660", "r12": "0x000000000000000c", "r13": "0x00007fff9c00db40", "r14": "0x000070000bf87aa8", "r15": "0x0000000000000003", "r8": "0xfffffffffffff000", "r9": "0x0000000102c000d9", "rax": "0xe5e5e5e5e5e5e5e5", // <--- Workaround: On OSX I can use "sudo killall VDCAssistant" to reset the camera into a good state, which gets out of the situation where it crashes.

I cannot reproduce the issue with my MBP (late 2016 model) STRs: 1. Share the built-in camera with https://jsfiddle.net/jib1/srn9db4h/ 2. close the lid while the camera is in use 3. open it again After step 3, Firefox doesn't show any prompt but keeps streaming without interruption.

I can reproduce this bug now.

After reverting this patch, I can still reproduce this bug. changeset: 365697:c846596b4cb8 user: Munro Mengjue Chiang <mchiang@mozilla.com> date: Thu Jun 22 14:22:10 2017 +0800 summary: Bug 1374938 - use our own avfoundation wrapper. r=jib

It's possible then it's one of the other ones in the regression range in comment 0. I'm having trouble reproducing, but will try it next time it happens.

Calling sec-moderate for now based on the described user interaction required, but if a web page could trigger this based on simple actions like getting a user to click that would be more concerning.

The NotReadableError situation happened again on my system, and I was able to narrow down the regression range further this time for some odd reason: 14:26.68 INFO: Last good revision: 7e2c3de976857db485370c5fdecf70990216847b 14:26.68 INFO: First bad revision: c846596b4cb8cd51375621dd43fc75e0a887c61a 14:26.68 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7e2c3de976857db485370c5fdecf70990216847b&tochange=c846596b4cb8cd51375621dd43fc75e0a887c61a Which points right at: Bug 1374938 - use our own avfoundation wrapper. r=jib

Was able to debug and find it. This appears to solve it.

Comment on attachment 8888045 [details] [diff] [review] Avoid double-delete on failure to init VideoCapture module. Review of attachment 8888045 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!

sec-moderate, so you can just land