Closed Bug 822040 Opened 10 years ago Closed 10 years ago

3D plugin causes crash to desktop

Categories

(Core Graveyard :: Plug-ins, defect)

20 Branch
All
Windows 7
defect
Not set
critical

Tracking

(firefox19 unaffected, firefox20 verified)

VERIFIED FIXED
mozilla20
Tracking Status
firefox19 --- unaffected
firefox20 --- verified

People

(Reporter: neils, Assigned: johns)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(1 file, 2 obsolete files)

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!
Is there an .apk link to download the plugin for testing in Firefox on Android, or does the site fallback to WebGL for mobile?
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: nobody → jschoenick
It's #2 top crasher in today's build.
Blocks: 556643
Keywords: topcrash
Hardware: x86_64 → x86
Whiteboard: [startupcrash]
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]
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 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+
Attached patch Test (obsolete) — Splinter Review
Attachment #692761 - Flags: review?(joshmoz)
(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+
Flags: in-testsuite+ → in-testsuite?
Attachment #692761 - Flags: review?(joshmoz) → review+
Rebased and folded
Attachment #692701 - Attachment is obsolete: true
Attachment #692761 - Attachment is obsolete: true
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+
Flags: in-testsuite? → in-testsuite+
Crash Signature: _NPStream*)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | mozilla::plugins::PluginModuleParent::StreamCast(_NPP* _NPStream*)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsStringBundle::GetStringFromName(nsAString_internal const… → _NPStream*) ] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsRefPtr<nsNPAPIPlugin>::nsRefPtr<nsNPAPIPlugin>(nsNPAPIPlugin*) | mozilla::plugins::PluginModuleParent::StreamCast(_NPP* _NPStream*) ] [@ mozalloc_abort(char const* const) | NS_Debu…
https://hg.mozilla.org/mozilla-central/rev/aba8a2ef6225
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
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.
(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.
(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
(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.
(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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.