Closed Bug 1589012 Opened 5 years ago Closed 5 years ago

Intermittent GECKO(5209) | SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/build/src/dom/media/encoder/MediaEncoder.cpp:111:5 in mozilla::MediaEncoder::AudioTrackListener::NotifyQueuedChanges

Categories

(Core :: Audio/Video: Recording, defect, P5)

Product:
Core
Component:
Audio/Video: Recording
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1586903

People

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

Details

(Keywords: intermittent-failure)

Filed by: pehrsons [at] gmail.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=271383825&repo=try
Full log: https://queue.taskcluster.net/v1/task/MIU7pnTvRs6nTHtzGeSOAw/runs/0/artifacts/public/logs/live_backing.log

There's a race that can occur when shutting down a MediaEncoder. Per the below sequence:

  • AudioTrackListener::NotifyQueuedChanges checks mShutdown, which is false
  • MediaEncoder::Shutdown calls AudioTrackListener::NotifyShutdown, setting mShutdown to true
  • MediaEncoder::Shutdown dispatches a runnable to shut down the encode thread
  • The encode thread shutdown runnable runs
  • AudioTrackListener::NotifyQueuedChanges tries to dispatch a runnable to the encode thread

Seems crazy unlikely that the audio thread would block that long, but why not.

(In reply to Treeherder Bug Filer from comment #0)

  • MediaEncoder::Shutdown dispatches a runnable to shut down the encode thread

My bad, the encode thread shutdown comes from MediaRecorder, but even there it's an extra main thread dispatch away from MediaEncoder::Cancel() which dispatches MediaEncoder::Shutdown() to the encoder thread.

Still "crazy unlikely, but why not" IMO.

Assignee: nobody → apehrson
Status: NEW → ASSIGNED

Ah, this is bug 1586903.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.