828216 - crash in nsNPAPIPluginInstance::SetWindow with Sibelius Scorch plugin

Status: RESOLVED WONTFIX

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

Description

[Scoobidiver (away)]

With combined signatures, it's #1 top crasher on Mac OS X in the first hours of 18.0.

It happens with the Sibelius Scorch plugin (http://www.sibelius.com/products/scorch/index.html).

Signature 	nsNPAPIPluginInstance::SetWindow More Reports Search
UUID	c0ba2f21-0419-49a2-a730-b17d12130109
Date Processed	2013-01-09 04:39:44
Uptime	11
Install Age	3.2 minutes since version was first installed.
Install Time	2013-01-09 04:36:14
Product	Firefox
Version	18.0
Build ID	20130104151948
Release Channel	release
OS	Mac OS X
OS Version	10.6.8 10K549
Build Architecture	x86
Build Architecture Info	family 6 model 23 stepping 10
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x500
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x 869GL Context? GL Context+ GL Layers? GL Layers+ 
Processor Notes 	/data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x 869

Frame 	Module 	Signature 	Source
0 		@0x500 	
1 	XUL 	nsNPAPIPluginInstance::SetWindow 	dom/plugins/base/nsNPAPIPluginInstance.cpp:567
2 	XUL 	nsPluginHost::PluginCrashed 	dom/plugins/base/nsPluginHost.cpp:4023
3 	XUL 	nsPluginNativeWindow::CallSetWindow 	dom/plugins/base/nsPluginNativeWindow.h:65
4 	XUL 	nsPluginInstanceOwner::FixUpPluginWindow 	dom/plugins/base/nsPluginInstanceOwner.cpp:3546
5 	AppKit 	stub helpers 	
6 	XUL 	nsXULPopupManager::GetInstance 	layout/xul/base/src/nsXULPopupManager.cpp:167
7 	XUL 	nsChildView::Resize 	widget/cocoa/nsChildView.mm:865
8 	libobjc.A.dylib 	objc_exception_try_exit 	
9 	XUL 	nsChildView::Resize 	widget/cocoa/nsChildView.mm:865
10 	XUL 	nsChildView::Resize 	widget/cocoa/nsChildView.mm:898

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsNPAPIPluginInstance%3A%3ASetWindow
https://crash-stats.mozilla.com/report/list?signature=%400x0+|+nsNPAPIPluginInstance%3A%3ASetWindow
https://crash-stats.mozilla.com/report/list?signature=Scorch%400x81e6

Comment 1

[Benjamin Smedberg]

This probably won't be hard to reproduce... it may be x86-only and not appear when running in amd64 arch (or the plugin may not work in amd64).  I'd love to have STR so we can find a regression range etc.

I'm a little surprised that the scorch plugin would show up high; it's primarily used to display sheet music.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Here's a page that loads a "Sibelius score" (mime type application/x-sibelius-score):
http://musicteachtech.wikispaces.com/Sibelius+Scorch+Sandbox

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Attachment: Example of Sibelius score

Here's the Sibelius score loaded by the page from comment #2.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

After installing the Sibelius Scorch plugin, in FF 18 I crash every time I try to load either the page from comment #2 or the Sibelius score from comment #3.

If I run FF 18 in 64-bit mode (the default), FF prompts me to restart in 32-bit mode, and then FF crashes as it's restarting.  Here's an example:

bp-885d3e59-264e-43df-b31f-916292130109

I also crash if I try to load either example in FF 18 after setting it to use 32-bit mode.  But in this case I see Apple's crash reporter (not a Breakpad dialog).

Next I'll check whether or not Sibelius Scorch uses the Carbon event model -- which is the only reason I'm aware of that we'd prompt to restart in 32-bit mode.  Note that the Carbon event model is about to desupported (in FF 19, see bug 598397).

Comment 5

[juan becerra [:juanb]]

I saw the same behavior as Steven. In Fx17.0.1 you load the page, the browser seems to freeze for a while, there's an unresponsive script error, then it prompts you to restart in 32bit mode. After the restart the plugin loads fine in Fx17 but it crashes in Fx18.

Comment 6

[juan becerra [:juanb]]

It happens in Fx18b1. I'll drill down from there.

Comment 7

[juan becerra [:juanb]]

It works on the nightly builds from 8/30 but I get an Apple problem report with the build from 8/31 after I restart in 32bit mode.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=706174d31a02&tochange=fcc533f691e9

Comment 8

[juan becerra [:juanb]]

Attachment: problem report for Nightly from 8/31

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I'll bet the killer here is:

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

 Bug 598401: Remove support for the Quickdraw NPAPI drawing model. r=smichaud
author	Josh Aas <[e-mail]>
	Thu Aug 30 15:10:55 2012 -0400 (at Thu Aug 30 15:10:55 2012 -0400)

In which case there's really nothing we can do (except to fail more neatly).

But let me bisect to confirm this.

Comment 10

[Benjamin Smedberg]

Is there ever any reason to prompt people to restart in 32-bit mode, then? If we detect that a plugin is using quicktime, we should eagerly stop that instance...

Comment 11

[Steven Michaud [:smichaud] (Retired)]

The Quickdraw drawing model and the Carbon event model are two different things, and need not always go together.  For example you can use the Carbon event model with the CoreGraphics drawing model.

We technically (til FF 19) still support the Carbon event model.  But as of FF 18 we've dropped support for the QuickDraw drawing model.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I've used a debug logging patch to confirm that the Sibelius Scorch plugin uses the Carbon event model.  I'll post the patch later, for reference.

But I haven't yet confirmed that it uses the QuickDraw drawing model.  That'll take a bit longer.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #9)

Josh's patch for bug 598401 *is* the trigger.

Which shows that Sibelius Scorch plugin uses both the Carbon event model and the QuickDraw drawing model.  It doesn't query the browser whether one or the other is supported, and doesn't ever set the event model or drawing model.  It just assumes both, since (presumably) both have historically been the default.

This fact alone shows that the Sibelius Scorch Mac plugin hasn't been properly maintained for a long time.  It's also interesting that the Scorch home page (http://www.sibelius.com/products/scorch/index.html) says that it's no longer supported in current versions of either Safari or Chrome.

Which is really too bad, since Sibelius 7 (which creates the files Scorch reads) seems to be the premier software for creating music scores (http://en.wikipedia.org/wiki/Sibelius_%28software%29).

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Firefox (pre 18) is the last major browser that supports Sibelius Scorch on the Mac.  So we're presented with a very uncomfortable choice -- either restore support (presumably temporarily) for the QuickDraw drawing model and the Carbon event model, or piss off a lot of music students and professionals who use OS X.

I know most programmers (presumably including Ben Smedberg and Josh Aas) would say "to hell with them for failing to maintain their plugin on OS X".  And I tend to agree.  But we should at least consider the alternative.

In the meantime I'll be working on a patch that causes plugins like Scorch to fail more cleanly.

Note that these crashes also happen on the trunk, where both the QuickDraw drawing model and the Carbon event model have been desupported.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I think someone should at least try to reach out to Sibelius Software (now owned by Avid Technology):  http://en.wikipedia.org/wiki/Avid_Technology

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb stack trace of crash in 32-bit mode, current trunk code

Comment 17

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #16)

Note that the crash happens in the plugin's main() method.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Attachment: Debug logging patch (*not* a fix)

Here's my debug logging patch, for reference (including my own future reference).

I've started a tryserver build, for those who are curious.

Comment 19

[Benjamin Smedberg]

Let's not debate the relative merits of music notation software... I have very informed opinions but they don't really help us here. We *knew* that disabling these things would cause minority plugins to fail, and I still think it's the right decision.

We should blocklist this plugin (I'll file a separate bug). We should also try and make sure that plugins which don't set a event/graphics model which we support are torn down quickly and don't have a chance to crash making assumptions which are no longer valid.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #19)

I wasn't discussing the relative *merits* of music notation software -- just the presumed size (and sophistication) of Sibelius' user base.

So the question becomes, how big (and visible) does that user base have to be to no longer be a "minority".

I don't know.  And I don't think any of us can know until we see how the world reacts.

(Note that I don't use any music notation software, and know nothing about it.  And before this bug appeared I'd never heard of the Sibelius Scorch plugin.)

Comment 21

[Scoobidiver (away)]

A workaround is to use Firefox 17 ESR but I think people will downgrade to 17.0.1 and stay with it.

To know how popular this plugin is, you can check URLs (how many domains?) and estimate users affected. For the second, there are currently 30 affected users (single install time) amongst 459*0.08 = 37kADU on Mac (market share of 8%), so less than 0.1%.

Comment 22

[Marcia Knous [:marcia]]

Removing URLs keyword since it seems Steven was able to reproduce the issue.

Comment 23

[Scoobidiver (away)]

(In reply to Marcia Knous [:marcia] from comment #22)
> Removing URLs keyword since it seems Steven was able to reproduce the issue.
It was to know how widespread that plugin is.

Comment 24

[Robert Kaiser]

URLs for Scorch@0x81e6:
23 	about:blank
4 	http://www.musicnotes.com/get/downscor.asp?...
2 	http://www.musicroom.com/se/id_no/0607626/details.html
2 	http://www.scoreexchange.com/scores/96576.html
1 	file:///Users/paula/Documents/%20%20%20CHOIR%20STUFF/EKOS/...
1 	https://www.sheetmusicdirect.us/ecom/myAccount/productDetail.do?itemId=1000118050&...
1 	http://www.musicroom.com/se/id_no/0614518/details.html
1 	http://www.scoreexchange.com/scores/99662.html
1 	http://www.scoreexchange.com/scores/97605.html
1 	https://www.music44.com/Merchant2/merchant.mvc
1 	http://www.gettymusic.com/customerarea.aspx
1 	http://www.musicroom.com/se/id_no/0615102/details.html
1 	http://www.virtualsheetmusic.com/score/HL-149984.html?tab=scorch
1 	http://www.greatscores.com/p/arrange/arrangementgsn/1091718/simple.html
1 	https://www.jwpepper.com/sheet-music/order/testscorch.jsp
1 	https://sheetmusicdirect.us/ecom/myAccount/productDetail.do?itemId=1000059448&...
1 	http://www.greatscores.com/de/Besame_Mucho/noten/1068477#

URLs for the other signatures are fewer and similar. I shortened those that seemed to have session IDs or something like that in them.

Comment 25

[Scoobidiver (away)]

It's currently #18 top browser crasher in 18.0.1 on Mac OS X so no longer a top crasher.

Comment 26

[Benjamin Smedberg]

Does that mean that the plugin blocklist is not effective? I would expect it to have disappeared almost entirely.

Comment 27

[Scoobidiver (away)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
> Does that mean that the plugin blocklist is not effective? I would expect it
> to have disappeared almost entirely.
The blocklisting may take time to propagate to every users. In addition, the plugin can be re-enabled manually for those who don't have admin rights to install a newer version of Scorch.

Comment 28

[Benjamin Smedberg]

Users can enable a plugin that is hard-blocklisted? I thought "hard" meant "no override". Do we need to have a new even-harder blocklist type that is basically "this plugin cannot work and we won't enable it ever"?

Comment 29

[Jorge Villalobos [:jorgev] (he/him)]

The plugin is softblocked, meaning that users can enable it if they choose to. Hardblocking is only used in the case of malicious add-ons.

Comment 30

[Benjamin Smedberg]

Jorge, I don't think that is the right decision in this case. The plugin *cannot* work in Firefox, so there is no point in allowing users to enable it. This really should be a hardblock. I'd like to get this off the radar; should I reopen the original blocklist bug, morph this one, or file a new one?

Comment 31

[Jorge Villalobos [:jorgev] (he/him)]

This is blocklisting policy. We won't hardblock anything that is not malicious. Unless crashes are still exploding due to users enabling the plugin by hand, which I find doubtful, I don't see why this is a problem.

Comment 32

[Benjamin Smedberg]

I disagree with that policy, but I guess in this case it's not important enough to worry about.