http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/cedar-macosx64-debug/1421461740/cedar_yosemite-debug_test-mochitest-other-bm108-tests1-macosx-build0.txt.gz is how every debug mochitest-other on 10.10 goes. We have five assertions ("bad inline size: 'metrics.ISize(lineWM) >= 0", dunno why a caps test hits layout asserts, but that's not the current problem) in caps/tests/mochitest/test_bug995943.xul, then several more failures in mochitest-chrome, then we start running mochitest-a11y, hit a timeout in jsat/test_content_text.html, and take a screenshot. http://mozilla-releng-blobs.s3.amazonaws.com/blobs/cedar/sha512/552589846e100808616b4a8718e4ae2fd601304c3ec7422ecd59755165e97eb73353107feb1c7fc674bf86af356f86c0fa7f52cc01c00c20183a5f6ee2a6be8c And that is the current problem, since it shows an OS dialog up over the top of Firefox, saying "atos needs to take control of another process for debugging to continue. Type the name and password of a user in the "Developer Tools" group to allow this." Unknowable how many of our other 10.10 debug failures are the result of that, but it's almost certainly the cause of mochitest-a11y's destruction, since a11y tests hate trying to run underneath an OS dialog (and thus hate their life, having to run after mochitest-chrome, which is prone to leaving things up like that).

Boy, this is terrible. I'll see if I can dig up anything.

I'm not actually sure where the call to atos happens, I was suspecting https://dxr.mozilla.org/mozilla-central/source/tools/rb/fix_macosx_stack.py but we're passing --symbols-path here so we shouldn't be using that file. I don't want to over-rotate on that, but I am kinda interested. There is this code path if we hit an unhandled ObjC exception: https://hg.mozilla.org/mozilla-central/annotate/34e2d2bd7ec4/xpcom/base/nsObjCExceptions.h#l101 so it might be that. Regardless, I think we need to add whatever user buildbot runs tests as to the developers group to make this work. This seems like the right answer: http://superuser.com/a/439502/29304

I'll run this command on a 10.10 slave and then retrigger the job on it to see if it resolves the problem. If so, I can add it to our puppet config

Looks like this is fixing the issue, I have a puppet patch to address it, just have to tweak it a bit. Thanks Ted for finding the article on how to set this preference.

Patch to enable DevToolsSecurity on 10.10 platforms and add cltbld to the _developer group so that debug tests can run 10.10. Tested in staging.

Comment on attachment 8553780 [details] [diff] [review] bug1122875.patch and merged to production

Verified that the puppet patch sets the appropriate permissions on a recently puppetized slave

Verified the tests pass on try. https://treeherder.mozilla.org/#/jobs?repo=try&revision=985356af18a4