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

RESOLVED FIXED

Status

Release Engineering
Platform Support
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: philor, Assigned: kmoir)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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
(Assignee)

Comment 3

3 years ago
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
(Assignee)

Comment 4

3 years ago
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)

Updated

3 years ago
Assignee: nobody → kmoir
(Assignee)

Comment 5

2 years ago
Created attachment 8553780 [details] [diff] [review]
bug1122875.patch

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)

Updated

2 years ago
Attachment #8553780 - Flags: review?(coop) → review+
(Assignee)

Comment 6

2 years ago
Comment on attachment 8553780 [details] [diff] [review]
bug1122875.patch

and merged to production
Attachment #8553780 - Flags: checked-in+
(Assignee)

Comment 7

2 years ago
Verified that the puppet patch sets the appropriate permissions on a recently puppetized slave
(Assignee)

Comment 8

2 years ago
Verified the tests pass on try.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=985356af18a4
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.