Closed Bug 1122875 Opened 9 years ago Closed 9 years ago

When getting a stack for an assertion, OS X 10.10 puts up a dialog asking for permission for atos to take control of another process

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: philor, Assigned: kmoir)

References

Details

Attachments

(1 file)

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.
Assignee: nobody → kmoir
Attached patch bug1122875.patchSplinter Review
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.
Attachment #8553780 - Flags: review?(coop)
Attachment #8553780 - Flags: review?(coop) → review+
Comment on attachment 8553780 [details] [diff] [review]
bug1122875.patch

and merged to production
Attachment #8553780 - Flags: checked-in+
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
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: