Closed Bug 1378944 Opened 7 years ago Closed 7 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | gfx/layers/apz/test/mochitest/test_wheel_scroll.html | application timed out after 330 seconds with no output


(Core :: Security: Process Sandboxing, defect)

Not set



Tracking Status
firefox57 --- fixed


(Reporter: intermittent-bug-filer, Assigned: kats)


(Blocks 1 open bug)


(Keywords: intermittent-failure, Whiteboard: [stockwell fixed:other]sb+)


(1 file)

Log contains this:

Sandbox: seccomp sandbox violation: pid 1131, tid 1200, syscall 241, args 0 128 3685376576 4293294352 3685376704 3685376712.  Killing process.

And then the dead process causes the test to time out.
Component: Panning and Zooming → Security: Process Sandboxing
On x86_64 syscall 241 is |__NR_mq_unlink|, on x86_32 it's |__NR_sched_setaffinity|.
Those numbers in comment #1 look very 32-bit (also, Treeherder shows it's a 32-bit job).

This seems to be used by Chaos Mode:

What I don't understand is why this would be intermittent, or would have started recently — the code in question seems to have been present (and enabled for this test) for years.
Two bugs filed with this failure today after not seeing it ever before. Something must have changed recently to start triggering this.
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #3)
> This seems to be used by Chaos Mode:
> 5e1e8d2f244bd8c210a578ff1f65c3b720efe34e/xpcom/threads/nsThread.cpp#467

I would propose whitelisting the syscall via our preferences, specifically for tests that rely on Chaos Mode?
Whiteboard: sblc3
We could also remove chaos mode from the tests. I don't think the tests *rely* on it, they just use it because it flushes out intermittent bugs faster, but I don't know if they really provide that much value.
This particular chaos mode feature, as it's used here, seems to apply only to threads started while the test is running.  That might help explain why it's intermittent and started happening recently.  But also, I'm not sure how much it's helping in that case.

If it were enabled at process startup it might be more useful, and then we could check for it when creating the sandbox policy so we wouldn't have to change anything for non-test usage.
Blocks: sb-test
Whiteboard: sblc3 → sb+
So what should we do here? Is somebody going to whitelist/work around this in the code, or should I just remove the chaos-mode annotation?
Flags: needinfo?(jld)
I'd say we should remove the chaos mode annotations.

They don't seem to really be doing anything useful at present; you'd need to enable the thread scheduling changes early in startup so they apply to all threads, at which point it'd be easy to test for it when building the sandbox policy.
Flags: needinfo?(jld)
Assignee: nobody → bugmail
Comment on attachment 8897151 [details]
Bug 1378944 - Stop running some APZ mochitests with chaos mode since it causes sandbox failures and doesn't provide much value.
Attachment #8897151 - Flags: review?(jld) → review+
Pushed by
Stop running some APZ mochitests with chaos mode since it causes sandbox failures and doesn't provide much value. r=jld
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Whiteboard: sb+ → [stockwell fixed:other]sb+
You need to log in before you can comment on or make changes to this bug.