When I execute the test_peerConnection_basicH264.html test locally on my machine the plugin apparently keeps crashing. I get a yellow warning at the top of the content window and mochitest point at minidumps left over at the end of the test run. Right now it blocks me actually from executing all the test in our mochitest directory, as the test execution hangs once it gets to the H264 test. According to MDN the minidumps left behind are for Visual studio on Win only!? So how can I debug this issue?
Ehugg indicated in bug 1054704 that on Mac he sees this if the library is a link, but he doesn't see it if the library is a file (and we're green on Try, which packages the builds). Ted?
This was working for me locally when I wrote the patch, but it's also possible some other bits of the stack were broken that were masking the problem. (In reply to Nils Ohlmeier [:drno] from comment #0) > According to MDN the minidumps left behind are for Visual studio on Win > only!? > So how can I debug this issue? Minidumps are the format that Breakpad produces (they did originate with Microsoft). If you run "./mach buildsymbols" in your local tree and then grab a copy of minidump_stackwalk from http://hg.mozilla.org/build/tools/file/tip/breakpad/ you can run "minidump_stackwalk /path/to/minidump $objdir/dist/crashreporter-symbols" to get a stack out.
Probably the sandbox ruleset needs to be altered to take account of the different path to plugin-container. As I mentioned at bug 1012949 comment #105, I already want (on general principles) to use the full path to plugin-container when writing the sandbox rules. Hopefully doing that will also fix this bug. Until I find out otherwise, I'll work here on both problems together.
These crashes are indeed due to a sandbox access violation -- but a different one (not having to do with any part of the path to plugin-container). The violation (presumably) happens on all versions of OS X. But, oddly, the crash doesn't happen on OS X 10.7 (and probably not on 10.8 either, though I haven't yet tested there). I see it only on OS X 10.9. This is probably why it doesn't happen on our tryservers (which all run 10.6 or 10.8, if I remember right). Once I've fixed this bug, I'll open another on the problem mentioned in bug 1012949 comment #105.
Assignee: nobody → smichaud
Turns out the problem is that Apple's sandbox rules need to contain paths to actual files and directories -- not links. This patch seems to fix it. I've started a set of tryserver builds: https://tbpl.mozilla.org/?tree=Try&rev=3d65e812e147
Attachment #8476765 - Flags: review?(rjesup)
Attachment #8476765 - Flags: review?(rjesup) → review+
Don't forget: > Once I've fixed this bug, I'll open another on the problem mentioned in bug 1012949 comment #105.
I've opened bug 1056936.
Comment on attachment 8476765 [details] [diff] [review] Fix Landed on mozilla-inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/edfcd8993e42
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Comment on attachment 8476765 [details] [diff] [review] Fix Approval Request Comment [Feature/regressing bug #]: Needed for uplift of bug 1012949 [User impact if declined]: FF 33 won't have Mac GMP sandboxing [Describe test coverage new/current, TBPL]: Baked for about a week on m-c [Risks and why]: Low risk (moderate for all bug 1012949 uplifts together) [String/UUID change made/needed]: none This patch should be uplifted together with the other patches listed in bug 1012949 comment #110.
Attachment #8476765 - Flags: approval-mozilla-aurora?
Attachment #8476765 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8476765 [details] [diff] [review] Fix Landed on mozilla-aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/9e9d7d4091e1
You need to log in before you can comment on or make changes to this bug.