Closed
Bug 822040
Opened 12 years ago
Closed 12 years ago
3D plugin causes crash to desktop
Categories
(Core Graveyard :: Plug-ins, defect)
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)
5.76 KB,
patch
|
johns
:
checkin+
|
Details | Diff | Splinter Review |
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
Comment 3•12 years ago
|
||
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•12 years ago
|
Assignee: nobody → jschoenick
Comment 4•12 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•12 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•12 years ago
|
||
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+
Assignee | ||
Comment 7•12 years ago
|
||
Attachment #692761 -
Flags: review?(joshmoz)
Assignee | ||
Comment 8•12 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•12 years ago
|
Flags: in-testsuite+ → in-testsuite?
Assignee | ||
Comment 9•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=929983063860
status-firefox19:
--- → unaffected
Attachment #692761 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 10•12 years ago
|
||
Rebased and folded
Attachment #692701 -
Attachment is obsolete: true
Attachment #692761 -
Attachment is obsolete: true
Assignee | ||
Comment 11•12 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•12 years ago
|
Flags: in-testsuite? → in-testsuite+
Updated•12 years ago
|
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…
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/aba8a2ef6225
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Updated•12 years ago
|
Updated•12 years ago
|
tracking-firefox20:
? → ---
Comment 13•11 years ago
|
||
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•11 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.
Comment 15•11 years ago
|
||
Should I file a new bug for this signature from Comment 13?
Comment 16•11 years ago
|
||
(In reply to Scoobidiver from comment #14) I can reproduce very easy this plugin crash mentioned in Comment 13, on reload.
Comment 17•11 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.
Comment 19•11 years ago
|
||
(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•11 years ago
|
||
(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•11 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.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•