Closed Bug 1686681 Opened 2 years ago Closed 2 years ago

RDD crash in [@ __tcgetattr]

Categories

(Core :: Security: Process Sandboxing, defect, P5)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: gsvelto, Assigned: padenot)

References

(Blocks 2 open bugs)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files, 1 obsolete file)

Crash report: https://crash-stats.mozilla.org/report/index/ec41095d-88e9-4f95-aeca-571ab0210113

Reason: SIGSYS

Top 10 frames of crashing thread:

0 libc.so.6 __tcgetattr sysdeps/unix/sysv/linux/tcgetattr.c:38
1 libc.so.6 isatty sysdeps/posix/isatty.c:27
2 libavutil.so.56 av_log_default_callback ./debian/standard/src/libavutil/log.c:371
3 libavutil.so.56 av_log ./debian/standard/src/libavutil/log.c:411
4 libavcodec.so.58 ff_h2645_packet_split ./debian/standard/src/libavcodec/h2645_parse.c:506
5 libavcodec.so.58 decode_extradata_ps ./debian/standard/src/libavcodec/h264_parse.c:370
6 libavcodec.so.58 ff_h264_decode_extradata ./debian/standard/src/libavcodec/h264_parse.c:489
7 libavcodec.so.58 h264_decode_init ./debian/standard/src/libavcodec/h264dec.c:414
8 libavcodec.so.58 ff_frame_thread_init ./debian/standard/src/libavcodec/pthread_frame.c:853
9 libavcodec.so.58 avcodec_open2 ./debian/standard/src/libavcodec/utils.c:732

It seems that the ffmpeg code is calling ioctl(TCGETS, ...), the failing line is this one in the glibc sources.

It seems that it's ffmpeg's logging facilities that are messing with the tty - no idea why - but I wonder if we could just return a failure here instead of crashing.

I hadn't noticed all the crashes are lumped together in a single spike. Maybe it was just a developer messing around. Well, we can always use this for tracking in case it pops up again.

Looks like something else that we handled in the content process policy and needs to be copied into the RDD policy.

(I notice there's also a copy in the socket process policy; I don't know if we actually need that.)

See Also: → 1673188

Similar not as for bug 1685463: ffmpeg is off by default in RDD, because it is not fully working yet.

So we want to get it resolved eventually, obviously before we would pref on ffmpeg inside RDD. But not highest priority right now.

See Also: → 1685463
Summary: Crash in [@ __tcgetattr] → RDD crash in [@ __tcgetattr]
Blocks: RDD
Severity: -- → S4
Priority: -- → P5
Crash Signature: [@ __tcgetattr] → [@ __tcgetattr] [@ __GI___tcgetattr]

When doing (e.g.) MOZ_LOG=PlatformDecoderModule:4, ffmpeg ends up doing
ioctl(TCGETS, ...) via tcgetattr, and this crashes the RDD. We don't care
much about the result, so let's just say ENOTTY.

Assignee: nobody → padenot
Status: NEW → ASSIGNED

And remove some relevant copy-pasta.

Hardware: Unspecified → x86_64

Emilio: your patch somehow duplicates those from Paul

Flags: needinfo?(emilio)

Did we really mid-aired writing the patch? ;_;

Flags: needinfo?(emilio)
Attachment #9217852 - Attachment is obsolete: true
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c69111560c7d
Handle ioctl(TCGETS, ...) by saying this is not a TTY. r=jld
https://hg.mozilla.org/integration/autoland/rev/d4fd0765d177
Dedup a copy-pasted block computing a constant about TTY. r=jld
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.