If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Native stack traces for Linux sandbox failures on ASAN builds

RESOLVED FIXED in mozilla36



3 years ago
3 years ago


(Reporter: jld, Assigned: jld)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



3 years ago
ASAN builds disable the crash reporter, so an ASAN build's sandbox failure on TBPL shows only the syscall info (syscall number and argument registers), instead of also having a stack trace extracted from the minidump.  This is noticeably not ideal for determining the root cause of such a crash.

ASAN, unsurprisingly, handles segfaults by logging useful information like a stack trace.  If that unwinder can deal with signal handler frames, then it would suffice to kill the process with a MOZ_CRASH (or equivalent) rather than reraising the SIGSYS.

Comment 1

3 years ago
It gets worse.  ASAN's crash reporter does lots of stuff that violates the sandbox policy — starting with tcgetattr() on stderr and proceeding into trying to rummage around in /proc to symbolicate the stack trace.  So this has probably been breaking ASAN/LSAN coverage of media plugins for... a while.

This also means that segfaulting in response to sandbox violations won't work, unless it's possible to determine that we're not already in ASAN's crash handler, but NS_StackWalk or whatever we use for normal crashes might work.


3 years ago
Depends on: 1080803


3 years ago
See Also: → bug 1081242


3 years ago
No longer depends on: 1080803

Comment 2

3 years ago
Comment #1 is now its own bug.

Comment 3

3 years ago
Created attachment 8504185 [details] [diff] [review]
Attachment #8504185 - Flags: review?(gdestuynder)


3 years ago
Blocks: 1081242
See Also: bug 1081242
Comment on attachment 8504185 [details] [diff] [review]

Review of attachment 8504185 [details] [diff] [review]:

::: security/sandbox/linux/glue/SandboxCrash.cpp
@@ +90,5 @@
> +{
> +  // Skip 3 frames: one for this module, one for the signal handler in
> +  // libmozsandbox, and one for the signal trampoline.
> +  //
> +  // FIXME, bug 968531: This should use the signal context so it can

what happens there on ARM?
Attachment #8504185 - Flags: review?(gdestuynder) → review+

Comment 5

3 years ago
(In reply to Guillaume Destuynder [:kang] from comment #4)
> Comment on attachment 8504185 [details] [diff] [review]
> ::: security/sandbox/linux/glue/SandboxCrash.cpp
> > +  // FIXME, bug 968531: This should use the signal context so it can
> what happens there on ARM?

NS_StackWalk stops before it gets to the actual stack, so the callback is never called.

Also, it's not just ARM; there are also problems on x86.  NS_StackWalk uses frame pointers there, but the syscall instruction that raised SIGSYS is probably in libc, and libc is probably built with -fomit-frame-pointer, so it works only if the syscall instruction occurs before any reuse of %rbp by the libc code (and we still lose the address of whatever called into libc).

Even so, it's better than nothing, and it's likely to provide the information needed for bug 1080165, so I'd like to land the patch with some changes to the comment.

Comment 6

3 years ago
Created attachment 8504425 [details] [diff] [review]

Adjusted comment; carrying over r+.
Attachment #8504185 - Attachment is obsolete: true
Attachment #8504425 - Flags: review+

Comment 7

3 years ago
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.