822040 - 3D plugin causes crash to desktop

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[neils]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121215 Firefox/20.0
Build ID: 20121215030840

Steps to reproduce:

Install sView Plugin (http://www.sview.ru/en/download)

Visit here:

http://www.mtbs3d.com/index.php?option=com_content&view=article&id=13229:vrst-ces-around-the-bend&catid=35&Itemid=73

Click "3D Stereo"


Actual results:

Crash to desktop on current nightly build.


Expected results:

Should have shown 3D image in 3D.  Software worked until Firefox 17 was released.  There is another bug tracker for this that is supposedly resolved, and this CTD is a new problem.

https://bugzilla.mozilla.org/show_bug.cgi?id=767633 (original bug tracker)

I was told to make a new submission for this new problem.

This is a serious issue because our 3D website can't show 3D images!

Comment 1

[Mardeg]

Is there an .apk link to download the plugin for testing in Firefox on Android, or does the site fallback to WebGL for mobile?

Comment 2

[neils]

This isn't mobile Firefox.  This is referring to a stereoscopic 3D plugin that takes true 3D pictures and lets you view them on all available 3D displays in their proper format.  This includes AMD HD3D, Nvidia 3D Vision, 3D HDTVs, and more.

Regards,
Neil

Comment 3

[Matthias Versen [:Matti]]

bp-1982829f-ae96-4d01-b5a4-549df2121216 (similar signature as bug 556643)

from not working due to bug 818802 it directly started crashing with the fix for bug 767633 (which should fix 818802)

Last good nightly: 2012-12-14
First bad nightly: 2012-12-15

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b11065872128&tochan
ge=5ea1c76e4bb3

Comment 4

[Scoobidiver (away)]

It's #2 top crasher in today's build.

Comment 5

[John Schoenick [:johns]]

Attachment: Cleanup the channel when plugins reject their initial stream

So I accidentally recreated bug 802355 - we moved plugin spawning out of the
listener, but we still need to close the channel if OnStartRequest fails. The
crash is because the subsequent OnDataAvailable hits this runttime abort for an
unexpected channel :-/

Comment 6

[Josh Aas]

Comment on attachment 692701 [details] [diff] [review]
Cleanup the channel when plugins reject their initial stream

If we've created the same bug twice now, per your comment, then we really need a test. r+ but this should have a test when it goes in, or a good explanation for why we can't have a test.

Comment 7

[John Schoenick [:johns]]

Attachment: Test

Comment 8

[John Schoenick [:johns]]

(In reply to John Schoenick [:johns] from comment #7)
> Created attachment 692761 [details] [diff] [review]
> Test

So test_pluginstream_err has a comprehensive test for this already, but only runs the tests on <embed> tags, which take a different code path due to spawning the plugin prior to opening the channel. This expands it to test both tags, and catches the bug.

Comment 9

[John Schoenick [:johns]]

https://tbpl.mozilla.org/?tree=Try&rev=929983063860

Comment 10

[John Schoenick [:johns]]

Attachment: Cleanup the channel when plugins reject their initial stream. r=josh

Rebased and folded

Comment 11

[John Schoenick [:johns]]

Comment on attachment 692820 [details] [diff] [review]
Cleanup the channel when plugins reject their initial stream. r=josh

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

Comment 12

[Ed Morley [:emorley]]

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

Comment 13

[Mihai Morar, (:MihaiMorar)]

Following STR from Comment 0, Sview plugin is crashing on FF 20b1 on Windows 7 x64:

Crashes reports:
https://crash-stats.mozilla.com/report/index/bp-a7ea9450-5c74-47ab-b6d3-f82f02130221
https://crash-stats.mozilla.com/report/index/bp-a95f2f3a-f641-4da4-954f-ade162130221

Build:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0(20130220104816)

This is not fixed yet.

Comment 14

[Scoobidiver (away)]

(In reply to MarioMi (:MarioMi) from comment #13)
> https://crash-stats.mozilla.com/report/index/bp-a7ea9450-5c74-47ab-b6d3-
> f82f02130221
> https://crash-stats.mozilla.com/report/index/bp-a95f2f3a-f641-4da4-954f-
> ade162130221
It's not the same crash signature. In addition, there are no Firefox components in the stack trace so it's not Mozilla's fault.

Comment 15

[Mihai Morar, (:MihaiMorar)]

Should I file a new bug for this signature from Comment 13?

Comment 16

[Mihai Morar, (:MihaiMorar)]

(In reply to Scoobidiver from comment #14)

I can reproduce very easy this plugin crash mentioned in Comment 13, on reload.

Comment 17

[Scoobidiver (away)]

(In reply to MarioMi (:MarioMi) from comment #15)
> Should I file a new bug for this signature from Comment 13?
No. You are the only one to crash and Mozilla can't do anything to fix it.

Comment 18

[Mihai Morar, (:MihaiMorar)]

Based on Comment 14, Verified Fixed

Comment 19

[Paul Silaghi, QA [:pauly]]

(In reply to Scoobidiver from comment #17)
> No. You are the only one to crash and Mozilla can't do anything to fix it.
I can reproduce the plugin crash when clicking the above buttons or reloading.

Comment 20

[Georg Fritzsche [:gfritzsche]]

(In reply to MarioMi (:MarioMi) from comment #15)
> Should I file a new bug for this signature from Comment 13?

This is a 0-pointer access somewhere in that plugins code. Unless it's triggered by a regression in Firefox we don't need to file a bug on this.

Comment 21

[kirill]

(In reply to Paul Silaghi [QA] from comment #19)
> (In reply to Scoobidiver from comment #17)
> > No. You are the only one to crash and Mozilla can't do anything to fix it.
> I can reproduce the plugin crash when clicking the above buttons or
> reloading.
I tried FF 20b1 with your scenario without any crash on my system.