Closed Bug 760960 Opened 12 years ago Closed 12 years ago

crash in nsNPAPIPluginInstance::GetJSObject with LightShot plugin

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
13 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox13+)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox13 + ---

People

(Reporter: scoobidiver, Assigned: benjamin)

References

Details

(4 keywords, Whiteboard: [qa+])

Crash Data

Attachments

(1 file)

stack
6.81 KB, text/plain
Details 
It's #271 top browser crasher in 12.0, #1263 in 13.0b5, #295 in 13.0b6, #14 in 13.0b7. The regression range is:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=5dd4dde1d4eb&tochange=91bf09009594
It's likely a regression from bug Bug 759788.

Signature 	nsNPAPIPluginInstance::GetJSObject(JSContext*, JSObject**) More Reports Search
UUID	dd8261f9-b945-45a3-8c5c-4877e2120602
Date Processed	2012-06-02 12:46:43
Uptime	85
Last Crash	1.6 minutes before submission
Install Age	5.5 minutes since version was first installed.
Install Time	2012-06-02 12:40:29
Product	Firefox
Version	13.0
Build ID	20120531155942
Release Channel	beta
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 37 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0xad80138
User Comments	There was an update in firefox. now its getting crashed again and again...:(
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0a66, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.16.11.9133
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	True	
Total Virtual Memory	4294836224
Available Virtual Memory	3844378624
System Memory Use Percentage	50
Available Page File	5849452544
Available Physical Memory	2061496320

Frame 	Module 	Signature 	Source
0 		@0xad80138 	
1 	xul.dll 	nsNPAPIPluginInstance::GetJSObject 	dom/plugins/base/nsNPAPIPluginInstance.cpp:843
2 	xul.dll 	nsHTMLPluginObjElementSH::GetPluginJSObject 	dom/base/nsDOMClassInfo.cpp:9837
3 	xul.dll 	nsHTMLPluginObjElementSH::SetupProtoChain 	dom/base/nsDOMClassInfo.cpp:9614
4 	xul.dll 	xpc_UnmarkGrayObject 	js/xpconnect/src/xpcpublic.h:189
5 	xul.dll 	XPCWrappedNative::GetNewOrUsed 	js/xpconnect/src/XPCWrappedNative.cpp:709
6 	xul.dll 	XPCCallContext::Init 	js/xpconnect/src/XPCCallContext.cpp:157
7 	xul.dll 	XPCCallContext::Init 	js/xpconnect/src/XPCCallContext.cpp:186
8 	xul.dll 	mozilla::dom::binding::XPCOMObjectToJsval 	js/xpconnect/src/dombindings.cpp:113
9 	xul.dll 	mozilla::dom::binding::ListBase<mozilla::dom::binding::ListClass<nsIHTMLCollecti 	js/xpconnect/src/dombindings.cpp:1126

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsNPAPIPluginInstance%3A%3AGetJSObject%28JSContext*%2C+JSObject**%29
Is there any correlation with a specific plugin?
Keywords: needURLs
(In reply to Mats Palmgren [:mats] from comment #1)
> Is there any correlation with a specific plugin?
Here are correlations per module and extension:
    100% (88/88) vs.   0% (169/42706) npLightshot.dll (LightShot plugin)
        100% (88/88) vs.   0% (163/42706) 2.0.5.15
     99% (87/88) vs.   0% (179/42706) {394DCBA4-1F92-4f8e-8EC9-8D2CB90CB69B} (LightShot (screenshot tool))
          9% (8/88) vs.   0% (20/42706) 2.0.1
         90% (79/88) vs.   0% (159/42706) 2.5.0
Summary: crash in nsNPAPIPluginInstance::GetJSObject → crash in nsNPAPIPluginInstance::GetJSObject with LightShot plugin
I was able to reproduce this with Firefox 13.0b7 on Windows 7 64-bit with JRE 6u31 and LightShot 2.5.0 from AMO installed.

I don't have a definitive steps to reproduce. Here's what I did:

1) Start Firefox with a new profile
2) Install LightShot 2.5.0 from AMO and restart Firefox
> Thank You for installing LightShot page loads in a 2nd tab
3) Click the feather icon and select an area in the content of the tab
4) Click one of the activity buttons
5) Wait for the function to complete and then repeat from step 3 until a crash occurs
> Crash occurs when clicking the feather after performing one of the functions
With Firefox 13.0b6 I was unable to reproduce this crash, but I did get an OS crash. Here is the stack information.

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	firefox.exe
  Application Version:	13.0.0.4531
  Application Timestamp:	4fc4317c
  Fault Module Name:	StackHash_d569
  Fault Module Version:	6.1.7601.17514
  Fault Module Timestamp:	4ce7ba58
  Exception Code:	c0000374
  Exception Offset:	000ce653
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	1033
  Additional Information 1:	d569
  Additional Information 2:	d569a0891ed95f795592a1bfb725bdb8
  Additional Information 3:	791b
  Additional Information 4:	791baffc9e04f52f5d35d25d1190bd53
Attached file stack — 
It's easy to reproduce in a local mozilla-inbound debug build too.
The crash is in npLightshot.dll.
Keywords: needURLs
(In reply to Scoobidiver from comment #2)
> (In reply to Mats Palmgren [:mats] from comment #1)
> > Is there any correlation with a specific plugin?
> Here are correlations per module and extension:
>     100% (88/88) vs.   0% (169/42706) npLightshot.dll (LightShot plugin)
>         100% (88/88) vs.   0% (163/42706) 2.0.5.15
>      99% (87/88) vs.   0% (179/42706) {394DCBA4-1F92-4f8e-8EC9-8D2CB90CB69B}
> (LightShot (screenshot tool))
>           9% (8/88) vs.   0% (20/42706) 2.0.1
>          90% (79/88) vs.   0% (159/42706) 2.5.0

Lightshot only represents <1% of crashes in this bug, however. Based upon volume, doesn't this appear to be taking the place of bug 760190, which appeared to take the place of bug 719117?

We need to continue working on this in case we decide to roll a 13.0.1 for this issue. It'd be great to get a possible fix into our next beta.
Assignee: nobody → benjamin
Blocks: 759788
Today's correlations confirm it's 100% correlated to LigthShot:
* 13:0:
    100% (62/62) vs.   0% (117/30293) npLightshot.dll
     98% (61/62) vs.   0% (125/30293) {394DCBA4-1F92-4f8e-8EC9-8D2CB90CB69B}
* 12.0:
    100% (200/201) vs.   0% (319/101438) npLightshot.dll
     98% (196/201) vs.   0% (314/101438) {394DCBA4-1F92-4f8e-8EC9-8D2CB90CB69B}
It's #21 top browser crasher in 13.0b7 while only #191 in 12.0.
Based on the dupe volume in 13.0b7, it seems more easily reproducible in 13.0b7.
Adding [qa+] to track for QA. Please add qawanted if there is something specific you want tested.
Whiteboard: [qa+]
(In reply to Scoobidiver from comment #7)
> Today's correlations confirm it's 100% correlated to LigthShot:

Looks like I misread the correlation report. We should consider blocklisting.

First, QA - can you confirm that with the add-on disabled your STR are impossible?
Keywords: qawanted
(In reply to Alex Keybl [:akeybl] from comment #9)
> (In reply to Scoobidiver from comment #7)
> > Today's correlations confirm it's 100% correlated to LigthShot:
> 
> Looks like I misread the correlation report. We should consider blocklisting.
> 
> First, QA - can you confirm that with the add-on disabled your STR are
> impossible?

Not sure what you are asking for since my STR require Lightshot.
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #10)
> (In reply to Alex Keybl [:akeybl] from comment #9)
> > (In reply to Scoobidiver from comment #7)
> > > Today's correlations confirm it's 100% correlated to LigthShot:
> > 
> > Looks like I misread the correlation report. We should consider blocklisting.
> > 
> > First, QA - can you confirm that with the add-on disabled your STR are
> > impossible?
> 
> Not sure what you are asking for since my STR require Lightshot.

Babylon, for instance, installs both a DLL and an add-on - both of which change Firefox's behavior. It sounds like the answer is that we haven't found STR that work with the add-on disabled.
CC'ing Jorge on this bug to discuss the possibility of blocklisting LightShot.

* Crash comments suggest that this crash occurs on each browser startup for some users
* 44.746% of crashes are happening in the first minute
* On the flip side, our STR have not caused startup crashes yet

I think we should consider it given the high number of startup crashes. Anthony believes that an add-on blocklist addition will do the trick.
(In reply to Alex Keybl [:akeybl] from comment #11)
> > Not sure what you are asking for since my STR require Lightshot.
> 
> Babylon, for instance, installs both a DLL and an add-on - both of which
> change Firefox's behavior. It sounds like the answer is that we haven't
> found STR that work with the add-on disabled.

Right, we've not found STR that work with the add-on disabled. Though, we've not been instructed of correlations or leads which do not involve this add-on. I'm not convinced blocking LightShot will eliminate these crashes for ALL users, but it should remove LightShot from the equation and allow us to drill down if necessary.
Keywords: reproducible
I don't see a lightshot 2.5 on AMO:

https://addons.mozilla.org/en-US/firefox/addon/lightshot/versions/?page=1

lists 
Version 2.6.0 Released June 4, 2012 660.5 KB Works with Firefox 2.0 and later

    Source code released under Custom License
    What's this?

Version 2.0.1 Released June 18, 2011 660.5 KB Works with Firefox 2.0 and later
* moved from XPCOM to NPAPI plugin
* fixed 16bit color probrem (black screenshots)
* added "Search similar images" 

Is it possible that they released a fix late yesterday? Assuming there actually was a 2.5 version, can I get a copy of it? Cn I get in contact with the developers to discuss whether the problem was our or just in the plugin?
Yeah, the developer removed it from AMO yesterday. We have an archived version in bug 761339:

https://bugzilla.mozilla.org/attachment.cgi?id=630001
Depends on: 761339
There are 2 crashes in 13.0.1.
Keywords: topcrash
I worked with them, they had a refcounting error in NPRuntime goop which is now fixed in newer versions.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: