Closed Bug 624572 Opened 11 years ago Closed 11 years ago

Abort in content process receiving PAudio:SampleOffsetUpdate: "Error: Route error: message sent to unknown actor ID"

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
fennec 2.0+ ---

People

(Reporter: cjones, Assigned: kinetik)

References

Details

Attachments

(1 file)

STR
 (1) Load http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_480p_stereo.ogg
 (2) Go into full-screen mode
 (3) Exit full-screen mode

Not 100% reproducible, but not too hard.  I came across this on desktop while trying to reproduce bug 623728.

This appears to be a use-after-__delete__ of a PAudio actor.
tracking-fennec: --- → ?
I also just got this

###!!! ASSERTION: Start time must be before end time: 'startTime < endTime', file /home/cjones/mozilla/mozilla-central/content/media/nsBuiltinDecoderReader.cpp, line 212

Probably related.
tracking-fennec: ? → 2.0+
Also saw this

###!!! ASSERTION: Seek target should lie inside the first audio block after seek: '!audio || (audio->mTime <= seekTime && seekTime <= audio->mTime + audio->mDuration)', file /home/cjones/mozilla/mozilla-central/content/media/nsBuiltinDecoderStateMachine.cpp, line 1067
In the child, nsAudioStreamRemote::Shutdown deletes the AudioChild (via an event posted to the main thread).  If I understand the way protocol shutdown works (from https://developer.mozilla.org/en/IPDL/Tutorial#Subprotocol_Deletion), it seems like it's possible for the following ordering:

Child: AudioStreamRemote::Shutdown
Child: AudioChild::Send__delete__
Child: AudioChild destroyed
Parent: Timer Notify queued
Parent: AudioParent destroy received from Child
Parent: Notify runs, attempts to send to AudioChild and aborts

The only protection in place for this is checking mIPCOpen, which can't be true yet because the AudioParent destroy hasn't had time to run.
AudioParent::Recv__delete__() gets called on the main thread.  iirc, calling the mTimer->Cancel() should prevent the timer from firing, even if it is queued.
You could also make the __delete__() message parent->child and only send it after shutdown state has propagated child->parent->audiothread.

(In reply to comment #4)
> AudioParent::Recv__delete__() gets called on the main thread.  iirc, calling
> the mTimer->Cancel() should prevent the timer from firing, even if it is
> queued.

It's not usually a good idea to use Recv__delete__() to clean up state like pending timers; ActorDestroy() is better.  Recv__delete__() is invoked only when the other side sends the __delete__ message to that particular actor.  ActorDestroy() is called in that case too, but also for crashes and ancestor deletion.
Attached patch patch v0Splinter Review
Implements cjones's suggestions.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #503729 - Flags: review?(doug.turner)
Comment on attachment 503729 [details] [diff] [review]
patch v0

running with this for a bit.  not sure how to trigger the problem.  I think we want to land this soon to get further testing in b4.
Attachment #503729 - Flags: review?(doug.turner) → review+
Comment 0 has STR for the original bug, that were fairly reliable for me.  Or do you mean with the patch applied you haven't triggered the problem?
not using the same ogg files, but using a copy of the smaller version of the big bunny movie, i could not reproduce the problem with matt's patch.
Whiteboard: [needs landing]
http://hg.mozilla.org/mozilla-central/rev/7dc2ef0666bc
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Can't reproduce, marking verified.
Status: RESOLVED → VERIFIED
Depends on: 640113
You need to log in before you can comment on or make changes to this bug.