hangs in JS engine with cross fuzzer

NEW
Unassigned

Status

()

Core
JavaScript Engine
--
critical
5 years ago
a year ago

People

(Reporter: cpeterson, Unassigned)

Tracking

({crash, regression})

Trunk
All
Mac OS X
crash, regression
Points:
---

Firefox Tracking Flags

(firefox17 affected, firefox47 affected, firefox48 wontfix, firefox49 fix-optional, firefox-esr45 affected, firefox50 fix-optional, firefox51 fix-optional)

Details

(Whiteboard: [js:p3], crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
This bug was filed from the Socorro interface and is 
report bp-810d1dc2-96f0-4adc-822b-9cf192120809 .
============================================================= 

STR:
1. Run "cross_fuzz" browser stress test:
http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_msie_randomized_seed.html
2. Wait for a few minutes

AR:
Crash!

I believe this is a recent regression.

I have reproduced this crash on Nightly 8-08 and 8-09 on OS X 10.7.4 (Lion) and Nightly 8-09 on OS X 10.8.0 (ML).

On OS X 10.7, the browser crashed after about 1-10 minutes. On OS X 10.8, the browser crashed in 0-4 minutes, but usually in less than 1 minute.
(Reporter)

Comment 1

5 years ago
I also reproduced with Nightly 8-07 on OS X 10.8. I tested earlier builds on OS X 10.7, but I could not repro the crash (but maybe I didn't wait long enough).

Assuming Nightly 8-07 was the regression point, here is the pushlog from 8-06 to 8-07:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8d94fe7506a&tochange=1bbc0b65dffb
Do you have a crash stack?
(Reporter)

Comment 3

5 years ago
The stack trace from the linked crash reports is:

Frame   Module  Signature       Source
0       XUL     XPCWrappedNative::FindTearOff           xpcprivate.h:2631
1       XUL     XPCNativeInterface::GetNewOrUsed        ReentrantMonitor.h:80
2       XUL     nsThreadManager::GetIsMainThread        nsThreadManager.cpp:272
3       XUL     XPCConvert::NativeInterface2JSObject    XPCConvert.cpp:940
4       XUL     js::AutoCompartment::enter              jswrapper.cpp:445
5       XUL     NativeInterface2JSObject                nsXPConnect.cpp:1237
6       XUL     XUL@0x9dc31f    
7       XUL     nsXPConnect::WrapNativeToJSVal          nsXPConnect.cpp:1293
8       XUL     nsCSSStyleDeclSH::PreCreate     
9       XUL     XPCCallContext::XPCCallContext          XPCCallContext.cpp:31
10      XUL     xpc::WrapperFactory::PrepareForWrapping WrapperFactory.cpp:245 

bp-810d1dc2-96f0-4adc-822b-9cf192120809
bp-20e7626a-f7bf-4008-968c-cc5972120809
bp-ef5d2451-2be1-4570-bc59-0faa42120809
bp-e9767b09-9362-4016-a631-6eec82120809
bp-646cd035-17ac-4277-8154-ad1172120809
bp-f54ec5f5-bf76-45f3-9337-0d6922120809
bp-148b49b0-c76d-4297-9e80-38e222120809
bp-e54fa972-c167-4e4a-81a2-9e84f2120809
bp-97237563-1a28-4975-ae20-9345a2120809
bp-32b254aa-2aed-4880-b40f-a82532120809
Created attachment 650709 [details]
more complete stack from GDB

I was able to reproduce this fairly quickly on OSX 10.6, in GDB. The stack trace looks slightly different for me.

It looks like we're calling XPCWrappedNative::FindTearOff where |this| is NULL.

#0 XPCWrappedNative::FindTearOff js/xpconnect/src/XPCWrappedNative.cpp:1956
#1 XPCConvert::NativeInterface2JSObject js/xpconnect/src/XPCConvert.cpp:940
#2 NativeInterface2JSObject js/xpconnect/src/nsXPConnect.cpp:1237
#3 nsXPConnect::WrapNativeToJSVal js/xpconnect/src/nsXPConnect.cpp:1294
#4 xpc::WrapperFactory::PrepareForWrapping js/xpconnect/wrappers/WrapperFactory.cpp:245
#5 JSCompartment::wrap js/src/jscompartment.cpp:215
#6 JSCompartment::wrap js/src/jscompartment.cpp:327
#7 js::RemapWrapper (cx=0x12167db20, wobj=0x12ff96e00, newTarget=0x14b68c490) at /Users/amccreight/mz/cent2/js/src/jswrapper.cpp:1147
#8 js::RemapAllWrappersForObject js/src/jswrapper.cpp:1189
#9 JS_TransplantObject js/src/jsapi.cpp:1658
#10 xpc::TransplantObject js/xpconnect/wrappers/WrapperFactory.cpp:663
#11 XPCWrappedNative::ReparentWrapperIfFound js/xpconnect/src/XPCWrappedNative.cpp:1682
#12 XPCWrappedNative::RescueOrphans js/xpconnect/src/XPCWrappedNative.cpp:1795
#13 MoveWrapper js/xpconnect/src/nsXPConnect.cpp:1569
#14 nsXPConnect::MoveWrappers js/xpconnect/src/nsXPConnect.cpp:1693
#15 nsHTMLDocument::Open content/html/document/src/nsHTMLDocument.cpp:1503
#16 nsHTMLDocument::WriteCommon content/html/document/src/nsHTMLDocument.cpp:1687
#17 nsIDOMHTMLDocument_Write js/xpconnect/src/dom_quickstubs.cpp:13714
Bobby, this looks like your sort of thing.
(In reply to Andrew McCreight [:mccr8] from comment #4)
> Created attachment 650709 [details]
> more complete stack from GDB
> 
> I was able to reproduce this fairly quickly on OSX 10.6, in GDB. The stack
> trace looks slightly different for me.
> 
> It looks like we're calling XPCWrappedNative::FindTearOff where |this| is
> NULL.

Indeed. From the previous stack frame, this means that we're pulling the private off an XPCWN reflector when the private is null. Andrew and I have been running into a couple of such cases lately.

So anyway. |flat| (the reflector) appears to have been pulled off the wrapper cache of the underlying XPCOM object. This makes sense, because it looks like we don't update the wrapper cache until after the call to JS_TransplantObject.

You'd think that we'd hit this problem all over the place, because we call JS_WrapObject() in the target object all over the place during transplant. The reason we don't is that normally an object with a wrapper cache also implements PreCreate and requests one reflector per native (rather than one reflector per scope). And the call to WrapNativeToJSVal only happens if we go with one reflector per scope.

It's possible we're getting caught in all that funny business with PreCreate I had to add in PrepareForWrapping (see the mega comment). Either way, the next step is to figure out what kind of object we're wrapping here, and why it's being so funny about PreCreate. Andrew, do you want to investigate that? If you prefer, I can take this over solo, but co-op is always more fun. :-)
I'll try poking at this.
Assignee: nobody → continuation

Updated

5 years ago
Blocks: 765416
Well, it looks like the native involved is a DOMCSSDeclarationImpl.  I haven't figured out anything else yet.
I tried this again, and I just end up with various hangs in the JS engine. One in the GC, some inside the method JIT. The hangs were slightly odd in that the browser was definitely doing something (breaking again later would end up with a different stack), but I'm not sure what. Anyways, the original XPConnect problem seems to be gone, so I'm going to unassign myself here.
Assignee: continuation → nobody
Summary: crash in XPCWrappedNative::FindTearOff → hangs in JS engine with cross fuzzer
Assignee: nobody → general
Component: XPConnect → JavaScript Engine
I attempted to replicate a JS hang with Nightly 2012-12-02 on OSX ML by going to that URL. I got occasional "Install Error" "This search engine isn't supported by Nightly and can't be installed" but no hang in the browser. 

Is anyone able to replicate the JS in Comment 9?
(Reporter)

Comment 11

5 years ago
Naveed, I have not been able to reproduce this bug for a few weeks.
Whiteboard: [js:p3]
(Assignee)

Updated

3 years ago
Assignee: general → nobody
Crash volume for signature 'XPCWrappedNative::FindTearOff':
 - nightly(version 50):0 crashes from 2016-06-06.
 - aurora (version 49):2 crashes from 2016-06-07.
 - beta   (version 48):26 crashes from 2016-06-06.
 - release(version 47):70 crashes from 2016-05-31.
 - esr    (version 45):4 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       0       1       1       0
 - beta          3       2       5       3       4       8       1
 - release      12       7      13      10       8       8       7
 - esr           1       1       0       0       0       0       0

Affected platforms: Windows, Mac OS X, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
status-firefox48: affected → wontfix
status-firefox49: affected → fix-optional
status-firefox50: --- → fix-optional
status-firefox51: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.