640934 - Crash [@ xpc::WrapperFactory::Rewrap(JSContext*, JSObject*, JSObject*, JSObject*, unsigned int) ][@ xpc::AccessCheck::isChrome ] mainly with Video Download Helper and Norton extensions

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

It is a new crash signature in the trunk.
It starts showing up as #66 top crasher in 4.0 RC1.

Signature	xpc::WrapperFactory::Rewrap(JSContext*, JSObject*, JSObject*, JSObject*, unsigned int)
UUID	11427d4a-4e6f-4b9f-929f-bde852110310
Time 	2011-03-10 20:04:52.182100
Uptime	4320
Last Crash	4333 seconds (1.2 hours) before submission
Install Age	12139 seconds (3.4 hours) since version was first installed.
Product	Firefox
Version	4.0
Build ID	20110303194838
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 15 model 6 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x12c7e004
User Comments	
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0640, AdapterDriverVersion: 8.15.11.8593
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers-
WebGL? WebGL-

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	xpc::WrapperFactory::Rewrap 	js/src/xpconnect/wrappers/WrapperFactory.cpp:256
1 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:334
2 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:364
3 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:326
4 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:364
5 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:326
6 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:364
7 	mozjs.dll 	JS_WrapObject 	js/src/jsapi.cpp:1267
8 	xul.dll 	XPC_WN_OuterObject 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:858
9 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/src/xpconnect/src/xpcconvert.cpp:1372
10 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcconvert.cpp:487
11 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcprivate.h:3262
12 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1613
13 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4799
14 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:653
15 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
16 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:863
17 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5173
18 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1672
19 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
20 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
21 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
22 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1127

More reports at:
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=xpc%3A%3AWrapperFactory%3A%3ARewrap%28JSContext*%2C%20JSObject*%2C%20JSObject*%2C%20JSObject*%2C%20unsigned%20int%29

Comment 1

[Scoobidiver (away)]

It is #69 top crasher in 4.0.1 and #12 in 5.0b2.
Correlations with Video Download Helper still persist.

Comment 2

[Scoobidiver (away)]

I added the Mac crash signature.
It is #15 top crasher on Windows and #2 on Mac OS X in 5.0b2 over the last 3 days.

Comment 3

[Asa Dotzler [:asa]]

Tracking in case this doesn't go down after release when our audience broadens. We may need to blocklist if it's worse than in the past.

Comment 4

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

Adding developer to CC list.

Comment 5

[Michel Gutierrez]

Is there any tip to why this can be correlated to Video DownloadHelper ? The add-on is javascript only doing regular access to the internal components. 

There are about 6 million daily users of this add-on on Windows (mozilla stats). Can it be the reason why a high percentage of users experiencing the crash have this extension installed ?

From my experience at support, users who are reporting a crash using DownloadHelper are in fact saving a video to a corrupted file system location (generally a poorly mounted network drive). Note that DownloadHelper just uses the regular Firefox downloading service. It does not handle the download or file saving on its own. It just allows the user to choose the download directory.

Is there any way to reproduce the issue ? Does it happen at any special occasion (when detecting video/downloading/converting) ?

Note that version 4.8.3 is obsolete (not working on YouTube anymore after some changes on this site). Current version is 4.8.6 but it will be soon replaced by 4.9 (current beta http://www.downloadhelper.net/install-beta.php?version=4.9b3 ) which moves 25 XPCOM javascript components to a module implementation. If we can reproduce the issue, it's worth giving a try with those changes.

Comment 6

[Scoobidiver (away)]

(In reply to comment #5)
> Is there any tip to why this can be correlated to Video DownloadHelper ?
Here are 5.0 crash stats correlations by add-on version:
* Windows:
     85% (89/105) vs.   6% (1180/19956) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
         85% (89/105) vs.   6% (1179/19956) 4.8.6
* Mac OS X:
     83% (10/12) vs.  18% (77/422) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006) (4.8.6)

> Is there any way to reproduce the issue ? Does it happen at any special 
> occasion (when detecting video/downloading/converting) ?
Here are some user comments:
"Crash when Downloading"
"crash when used downloadhelper"
"Using download helper and clicked on copy URL to clipboard, then it crashed. http://soultherapynow.com/videos/carl-jung-wisdom-of-the-dream.html"
"i was opening video from dailiy motion after close another tab with video."

Comment 7

[Michel Gutierrez]

Where can i see the full comments list ? Maybe i will be able find a pattern there. The "Comments" tab at https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=xpc%3A%3AWrapperFactory%3A%3ARewrap%28JSContext*%2C%20JSObject*%2C%20JSObject*%2C%20JSObject*%2C%20unsigned%20int%29 doesn't show the "Using download helper and clicked on copy URL to clipboard ..." comment for instance. Hopefully other comments will help narrowing down the issue, as i have no clue for now.

Also, is there any way to know if this crash happened while people were running DownloadHelper version 4.9b1 ? From my records, it has been installed 3000 times (this beta is self hosted). 4.9x changed a lot of things in the internal structure of the add-on (this was done to improve startup performances), so maybe it will self resolve that crash.

Comment 8

[Scoobidiver (away)]

(In reply to comment #7)
> Where can i see the full comments list ?
In crashes for Mac:
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=xpc::AccessCheck::isChrome

(In reply to comment #7)
> Also, is there any way to know if this crash happened while people were
> running DownloadHelper version 4.9b1 ?
Click the "Correlations" tab and then click the "Load" button below "Add-ons by version". No crashes with this crash signature so far but only one crash in 4.0.1 with this extension version for the last day.
So 4.9b1 is not enough widespread to conclude that it is fixed.

Comment 9

[Michel Gutierrez]

Thanks. 

I plan to release 4.9 at the end of this week or early next week. Then we will quickly have enough data to see if it improves that issue.

By that time if anyone has an idea about how to correlate the stack dump with an operation the addon could do, i would gladly take it. So far, i can only see the crash is initiated by an event (don't know which one) reception.

Comment 10

[Michel Gutierrez]

(In reply to comment #8)
> (In reply to comment #7)
> > Where can i see the full comments list ?
> In crashes for Mac:
> https://crash-stats.mozilla.com/report/
> list?range_value=4&range_unit=weeks&signature=xpc::AccessCheck::isChrome

Doing a search from https://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&range_value=4&range_unit=weeks&date=06%2F11%2F2011+00%3A56%3A45&query_search=signature&query_type=contains&query=Rewrap&reason=&build_id=&process_type=any&hang_type=any&do_query=1 on crash signature containing 'Rewrap', it shows this particular crash happened 8263 times on Windows, never on Mac nor Linux. So we can assume this is a Windows only crash.

Comment 11

[Scoobidiver (away)]

> So we can assume this is a Windows only crash.
No. There are one kind of crash signature for Windows and another one for Mac/Linux that only differ with the first frame, so it is the same crash.
* Mac top stack traces:
0 	XUL 	xpc::AccessCheck::isChrome 	js/src/xpconnect/wrappers/AccessCheck.cpp:59
1 	XUL 	xpc::WrapperFactory::Rewrap 	js/src/xpconnect/wrappers/WrapperFactory.cpp:256
2 	XUL 	JSCompartment::wrap 	js/src/jscompartment.cpp:334
* Windows top stack traces:
0 	xul.dll 	xpc::WrapperFactory::Rewrap 	js/src/xpconnect/wrappers/WrapperFactory.cpp:256
1 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:334

Comment 12

[Michel Gutierrez]

I submitted Video DownloadHelper 4.9 to amo editors.

As we don't know for sure why it crashes (the add-on only runs regular javascript code) and with the major internal architecture change, it is possible this crash will disappear.

Comment 13

[Marcia Knous [:marcia]]

2011060815145 which is the Beta 5 build has 132 Windows crashes so far. Across all versions 2451 Windows crashes in one week. We can see what happens once 4.9 is out - 4.8.6 is still currently on AMO.

Comment 14

[LegNeato]

Jorge, can we expedite this review?

Comment 15

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

Version 4.9 has just been approved for the public.

Comment 16

[Marcia Knous [:marcia]]

I can confirm Version 4.9.1 is now on AMO.

Comment 17

[Scoobidiver (away)]

I can also confirm that version 4.9.1 crashes. Here are 5.0 correlations by version:
76% (66/87) vs.   6% (1446/24378) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
  6% (5/87) vs.   1% (123/24378) 4.8.6
  3% (3/87) vs.   0% (98/24378) 4.9
67% (58/87) vs.   5% (1224/24378) 4.9.1
  0% (0/87) vs.   0% (1/24378) 4.9.2

Comment 18

[Michel Gutierrez]

I am not familiar with mozilla low level debugging but i recompiled a modified version of Firefox to trap a situation where xpc::WrapperFactory::Rewrap was reached while, higher in the stack, the js::RunScript was being called for a script whose file name started by "chrome://dwhelper". After playing several hours with this, i never reached that situation.
Is there any chance we can access a full memory dump that goes along with that crash stack signature ?
Do you suggest any instrumentation i can put to the add-on to help there ?

Comment 19

[Scoobidiver (away)]

It is #5 top browser crasher in 5.0.

Comment 20

[Marcia Knous [:marcia]]

Can someone help Michel with the memory dump he requests in Comment 18?

Comment 21

[(no longer active)]

(In reply to comment #20)
> Can someone help Michel with the memory dump he requests in Comment 18?

I've seen this crash on my brother's computer:

https://crash-stats.mozilla.com/report/index/a64be1bf-fbe0-45de-b3d6-565862110714

Is there any way that I can help you get that memory dump?

Comment 22

[Marcia Knous [:marcia]]

#18 top browser crash in Firefox 6 and present in other versions as well (FF 7) - would be good to make some headway on this. jst: can help with the memory dump?

Comment 23

[Scoobidiver (away)]

It's #17 top browser crasher (resp. #18) and #10 (resp. #9) top browser crasher without hangs on 6.0 (resp. 7.0b2)

Here are recent correlations on 6.0:
* Windows:
  xpc::WrapperFactory::Rewrap(JSContext*, JSObject*, JSObject*, JSObject*, unsigned int)|EXCEPTION_ACCESS_VIOLATION_READ (429 crashes)
     56% (239/429) vs.   5% (4753/88450) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
         55% (237/429) vs.   5% (4663/88450) 4.9.5
     33% (141/429) vs.  12% (10222/88450) {2D3F3651-74B9-4795-BDEC-6DA2F431CB62} (Norton toolbar)
         33% (140/429) vs.  11% (10162/88450) 2011.7.1.3
     33% (143/429) vs.  15% (13082/88450) {BBDA0591-3099-440a-AA10-41764D9DB4DB} (Norton IPS)
         33% (143/429) vs.  12% (10888/88450) 3.1
* Mac:
 xpc::AccessCheck::isChrome|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (13 crashes)
     54% (7/13) vs.  12% (258/2179) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
         54% (7/13) vs.  12% (251/2179) 4.9.5

Comment 24

[Marcia Knous [:marcia]]

This is still hanging around. 877 Windows crashes in the last week across all versions. There are also low volume Mac crashes so adding that signature. One of the latest Mac crashes with comments implicated version 4.9.8 which is the most recent version on addons.

Some recent correlations:

xpc::WrapperFactory::Rewrap(JSContext*, JSObject*, JSObject*, JSObject*, unsigned int)|EXCEPTION_ACCESS_VIOLATION_READ (10 crashes)
     60% (6/10) vs.   6% (3298/56926) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)

Adding Kev in case we have a contact there.

Comment 25

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

If you mean a contact with Video DownloadHelper, that would be Michel, who is already active in this bug.

Mig, did you see comment #21? What do you need in order to investigate this further?

Comment 26

[Michel Gutierrez]

Well, i spent time trying to reproduce the crash with an instrumented build of Firefox but without success. Apparently it crashes in the javascript interpretor but i can't see a way to locate what javascript code is being executed. Crash reports do not show any pattern in what the user is doing at that time.
Note that the DownloadHelper does not run any binary component, just plain javascript.
Any suggestion about how to address the issue is welcome.

Comment 27

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

per Comment 26