Closed Bug 832032 Opened 7 years ago Closed 7 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
firefox19 --- unaffected
firefox20 --- fixed
firefox21 --- fixed
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: johns, Assigned: johns)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Create the listener (which shouldn't fail) in OnStartRequest such that it's not
hanging around before there's a channel for it.
Blocks: 783059
Priority: -- → P2
Attachment #703612 - Flags: review?(joshmoz)
Attachment #703612 - Flags: review?(joshmoz) → review+
Is this possibly a new regression? See bug 827171, a topcrash on aurora.
(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.
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/jschoenick@mozilla.com-bdb2a1887144
Neglected to remove |if (!mFinalListener)| check. Carrying over r+
Attachment #703612 - Attachment is obsolete: true
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
Attachment #705601 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/a7115ec2354f
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
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
Attachment #705601 - Flags: approval-mozilla-aurora?
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
Attachment #705601 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.