Closed Bug 1341901 Opened 3 years ago Closed 3 years ago

DEBUG FUZZING builds with fuzzing.enabled set to true crash immediately

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: mccr8, Assigned: decoder)

References

Details

Attachments

(2 files)

After fixing bug 1341887, I still get a content process crash immediately on startup. I don't know what the cause is.

It looks like this:
[Child 11078] WARNING: '!compMgr', file /home/amccreight/mc/xpcom/components/nsComponentManagerUtils.cpp, line 63
++DOMWINDOW == 11 (0x7fcf51021800) [pid = 11030] [serial = 11] [outer = 0x7fcf5411d800]
[Child 11078] WARNING: '!compMgr', file /home/amccreight/mc/xpcom/components/nsComponentManagerUtils.cpp, line 63
PREEXISTING EXCEPTION OBJECT: 'NS_ERROR_XPC_BAD_OP_ON_WN_PROTO: Illegal operation on WrappedNative prototype object'
:0
Assertion failure: false (We had an exception; we should not have), at /home/amccreight/mc/dom/base/ScriptSettings.cpp:432

Maybe the component manager is getting called too early, and that cascades into some more severe failure.
Attached file assertion stack
Decoder, is this something you've seen?
Flags: needinfo?(choller)
Summary: fuzzing.enabled builds crash immediately → DEBUG FUZZING builds with fuzzing.enabled set to true crash immediately
Apparently this crash only happens with e10s enabled and when the fuzzing pref is set at the same time. There must be a difference in how the initialization works for the JS global object on e10s. I'm still investigating this, but it might well be that without the help from JS and e10s engineers, we might not be able to find the source of the problem here.
Flags: needinfo?(choller)
After further investigation, it appears that the crash is caused by the TestingProperties in the JS shell that are being added to the global object without JSPROP_RESOLVING while we are in a resolve hook. I wonder why this doesn't happen on non-e10s because I had a similar problem there with the testing functions (also requiring JSPROP_RESOLVING). Since there is only one property in TestingProperties and it is only required in the JS shell, jandem suggested to move it to js/src/shell/js.cpp and therefore making it shell only. I confirmed that this will fix the startup crash we see here, patch coming soon.
Assignee: nobody → choller
Comment on attachment 8843574 [details]
Bug 1341901 - Make timesAccessed property JS shell only.

https://reviewboard.mozilla.org/r/117240/#review118932

LGTM, thanks!
Attachment #8843574 - Flags: review?(jdemooij) → review+
Pushed by choller@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/97e94e028ed4
Make timesAccessed property JS shell only. r=jandem
https://hg.mozilla.org/mozilla-central/rev/97e94e028ed4
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.