don't stop for SIGSYS in .gdbinit

RESOLVED FIXED in Firefox 53

Status

()

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: froydnj, Assigned: froydnj)

Tracking

unspecified
mozilla53
Points:
---

Firefox Tracking Flags

(firefox53 fixed)

Details

Attachments

(1 attachment)

The sandboxing code generates this signal nowadays, which makes
debugging with tools like rr quite frustrating.
Picking jld because he probably understands the sandboxing code and how this
would interact with rr?  Feel free to redirect.
Attachment #8811024 - Flags: review?(jld)
Comment on attachment 8811024 [details] [diff] [review]
don't stop for SIGSYS in .gdbinit

Seems like a good idea — for all practical purposes, SIGSYS is now an implementation detail / expected side effect of calls like open(), and unless you're working on sandboxing or debugging a sandboxing issue you won't want to stop on it.

Printing the signal could have some value, but usually it will just be confusing and annoying, especially because gdb will stop and prompt after every screenful of messages, so turning that off is fine too.
Attachment #8811024 - Flags: review?(jld) → review+
As for rr, there were some issues with using the SIGSYS handler to polyfill syscalls with other syscalls but they've been fixed, so as far as I know it should now be faithfully reproducing the SIGSYS-related irritation level of a regular debugging session (modulo sometimes changing the direction of time).
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa4c2f76351d
don't stop for SIGSYS in .gdbinit; r=jld
https://hg.mozilla.org/mozilla-central/rev/fa4c2f76351d
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.