832032 - ###!!! ASSERTION: Received OnStopRequest for untracked request

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[John Schoenick [:johns]]

I ran into this:

235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: Channel opened
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: LoadObject called, notify 1, forceload 1, channel 0
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: Updating object parameters
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: Channel parameters changed
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: Type changed from 2 -> 0
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: LoadObject - plugin state changed (3)
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: StopPluginInstance - Closing used channel
235550528[7fe90cd4b370]: OBJLC [7fe8dc17ed48]: Closing channel
###!!! ASSERTION: Received OnStopRequest for untracked request.: 'Error', file /home/johns/moz/moz-git/dom/plugins/base/nsPluginStreamListenerPeer.cpp, line 901

While trying to finalize the test for bug 783059

In bug 767633 we moved opening plugin initial streams to nsObjectLoadingContent, but ::CloseChannel() assumes a listener would only exist if we had already hit OnStartRequest.

Comment 1

[John Schoenick [:johns]]

Attachment: Don't create a PluginStreamListener for initial plugin streams before OnStartRequest

Create the listener (which shouldn't fail) in OnStartRequest such that it's not
hanging around before there's a channel for it.

Comment 2

[Benjamin Smedberg]

Is this possibly a new regression? See bug 827171, a topcrash on aurora.

Comment 3

[John Schoenick [:johns]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Is this possibly a new regression? See bug 827171, a topcrash on aurora.

This should only ever send a superfluous OnStopRequest, but if it is somehow confusing nsPluginStreamListenerPeer's state, it could be related. It should be fairly safe otherwise, so I'll nom for aurora.

Comment 4

[Mozilla RelEng Bot]

Try run for bdb2a1887144 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=bdb2a1887144
Results (out of 28 total builds):
    success: 5
    warnings: 3
    failure: 20
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-bdb2a1887144

Comment 5

[John Schoenick [:johns]]

Attachment: Don't create a PluginStreamListener for initial plugin streams before OnStartRequest. r=josh

Neglected to remove |if (!mFinalListener)| check. Carrying over r+

Comment 6

[John Schoenick [:johns]]

Comment on attachment 705601 [details] [diff] [review]
Don't create a PluginStreamListener for initial plugin streams before OnStartRequest. r=josh

https://hg.mozilla.org/integration/mozilla-inbound/rev/a7115ec2354f

try:
https://tbpl.mozilla.org/?tree=Try&rev=9438dd76e6d4

Comment 7

[[Back July 11] Ryan VanderMeulen]

https://hg.mozilla.org/mozilla-central/rev/a7115ec2354f

Comment 8

[John Schoenick [:johns]]

Comment on attachment 705601 [details] [diff] [review]
Don't create a PluginStreamListener for initial plugin streams before OnStartRequest. r=josh

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
bug 767633

User impact if declined: 
Regression that could cause unknown plugin misbehavior

Testing completed (on m-c, etc.): 
On m-c

Risk to taking this patch (and alternatives if risky): 
Low, doesn't instantiate a listener until its channel is ready, which is similar to pre-767633 behavior.

String or UUID changes made by this patch:
None

Comment 9

[bhavana bajaj [:bajaj]]

Comment on attachment 705601 [details] [diff] [review]
Don't create a PluginStreamListener for initial plugin streams before OnStartRequest. r=josh

Low risk, reverts back to previous behavior.Approving on aurora

Comment 10

[[Back July 11] Ryan VanderMeulen]

https://hg.mozilla.org/releases/mozilla-aurora/rev/71e945235fd2