3D plugin causes crash to desktop

VERIFIED FIXED in Firefox 20

Status

()

--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: neils, Assigned: johns)

Tracking

({crash, regression, topcrash})

20 Branch
mozilla20
All
Windows 7
crash, regression, topcrash
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox19 unaffected, firefox20 verified)

Details

(crash signature)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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

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

Comment 2

6 years ago
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
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
Blocks: 767633
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsSVGSetElement>::nsRefPtr<nsSVGSetElement>(nsSVGSetElement*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP*, _NPStream*) ]
Component: Untriaged → Plug-ins
Ever confirmed: true
Keywords: crash, regression
Product: Firefox → Core
(Assignee)

Updated

6 years ago
Assignee: nobody → jschoenick

Comment 4

6 years ago
It's #2 top crasher in today's build.
Blocks: 556643
status-firefox20: --- → affected
tracking-firefox20: --- → ?
Keywords: topcrash
Hardware: x86_64 → x86
Whiteboard: [startupcrash]

Updated

6 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsSVGSetElement>::nsRefPtr<nsSVGSetElement>(nsSVGSetElement*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP*, _NPStream*) ] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsSVGSetElement>::nsRefPtr<nsSVGSetElement>(nsSVGSetElement*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP* _NPStream*)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P |…
Hardware: x86 → All
Whiteboard: [startupcrash]
(Assignee)

Comment 5

6 years ago
Created attachment 692701 [details] [diff] [review]
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 :-/
Attachment #692701 - Flags: review?(joshmoz)

Comment 6

6 years ago
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.
Attachment #692701 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 7

6 years ago
Created attachment 692761 [details] [diff] [review]
Test
Attachment #692761 - Flags: review?(joshmoz)
(Assignee)

Comment 8

6 years ago
(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.
Flags: in-testsuite+
(Assignee)

Updated

6 years ago
Flags: in-testsuite+ → in-testsuite?
(Assignee)

Comment 9

6 years ago
https://tbpl.mozilla.org/?tree=Try&rev=929983063860
status-firefox19: --- → unaffected

Updated

6 years ago
Attachment #692761 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 10

6 years ago
Created attachment 692820 [details] [diff] [review]
Cleanup the channel when plugins reject their initial stream. r=josh

Rebased and folded
Attachment #692701 - Attachment is obsolete: true
Attachment #692761 - Attachment is obsolete: true
(Assignee)

Comment 11

6 years ago
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
Attachment #692820 - Flags: checkin+
(Assignee)

Updated

6 years ago
Flags: in-testsuite? → in-testsuite+

Updated

6 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsSVGSetElement>::nsRefPtr<nsSVGSetElement>(nsSVGSetElement*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP* _NPStream*)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P |… → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsSVGSetElement>::nsRefPtr<nsSVGSetElement>(nsSVGSetElement*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP* _NPStream*) ] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P …
https://hg.mozilla.org/mozilla-central/rev/aba8a2ef6225
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20

Updated

6 years ago
status-firefox20: affected → fixed
tracking-firefox20: ? → ---
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

6 years ago
(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.
Should I file a new bug for this signature from Comment 13?
(In reply to Scoobidiver from comment #14)

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

Comment 17

6 years ago
(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.
Based on Comment 14, Verified Fixed
Status: RESOLVED → VERIFIED
status-firefox20: fixed → verified
(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.
(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

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.