Closed Bug 752309 Opened 12 years ago Closed 12 years ago
crash in xpc::Wrapper
Factory::Prepare For Wrapping
See testcase, which crashes current trunk build after 100ms. It doesn't crash Firefox beta, so looks like a regression. This bug was filed from the Socorro interface and is report bp-45061036-1b6c-406d-953f-b29442120506 . ============================================================= 0 xul.dll xpc::WrapperFactory::PrepareForWrapping js/xpconnect/wrappers/WrapperFactory.cpp:202 1 mozjs.dll JSCompartment::wrap js/src/jscompartment.cpp:184 2 mozjs.dll JS_CopyPropertiesFrom js/src/jsobj.cpp:3191 3 xul.dll XPCWrappedNative::ReparentWrapperIfFound js/xpconnect/src/XPCWrappedNative.cpp:1655 4 xul.dll MoveWrapper js/xpconnect/src/nsXPConnect.cpp:1670 5 xul.dll nsXPConnect::MoveWrappers js/xpconnect/src/nsXPConnect.cpp:1707 6 xul.dll nsContentUtils::ReparentContentWrappersInScope content/base/src/nsContentUtils.cpp:1702 7 xul.dll nsHTMLDocument::Open content/html/document/src/nsHTMLDocument.cpp:1526 8 xul.dll nsHTMLDocument::WriteCommon content/html/document/src/nsHTMLDocument.cpp:1703 9 xul.dll nsHTMLDocument::Write content/html/document/src/nsHTMLDocument.cpp:1752 10 xul.dll nsIDOMHTMLDocument_Write obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:13617 11 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:524
Component: DOM: Core & HTML → XPConnect
QA Contact: general → xpconnect
Crash stats are no longer connected with bugs (bug 749496?).
How did you run into this crash? Why it it concerning? Wondering what the user experience is that leads to this to get a sense of whether we need to track this.
Is there a reason why this is separate from bug 752164? I'm getting the two of them confused.
Because crash-stats didn't me give that bug id when I got this crash. Feel free to dupe this against that one or that one against this one.
(In reply to Lukas Blakk [:lsblakk] from comment #3) > How did you run into this crash? Why it it concerning? Wondering what the > user experience is that leads to this to get a sense of whether we need to > track this. It's a crash and a regression. I think it's a good idea in following regressions to have less crashes, not more.
The regression window is in bug 752164 comment 0.
No longer blocks: 752164
Crash Signature: [@ xpc::WrapperFactory::PrepareForWrapping(JSContext*, JSObject*, JSObject*, unsigned int)] → [@ xpc::WrapperFactory::PrepareForWrapping(JSContext*, JSObject*, JSObject*, unsigned int)] [@ xpc::WrapperFactory::PrepareForWrapping]
OS: Windows NT → All
Hardware: x86 → All
(In reply to Lukas Blakk [:lsblakk] from comment #3) > How did you run into this crash? Why it it concerning? Wondering what the > user experience is that leads to this to get a sense of whether we need to > track this. Being by far the #1 topcrash on 15.0a1 should be enough to warrant tracking, IMHO. Not sure why it's marked for 14 as well, as https://crash-stats.mozilla.com/report/list?range_value=28&range_unit=days&signature=xpc%3A%3AWrapperFactory%3A%3APrepareForWrapping%28JSContext*%2C%20JSObject*%2C%20JSObject*%2C%20unsigned%20int%29 makes it look like there were only 2 crashes in any 14.* version so far, and this signature has been a residual crash at very low level at least since FF5, apparently. The real regression to make this a topcrash only happened in 15.0a1 Nightly. In terms of regression window, The 2012050412 Build ID was the first one to see this signature according to https://crash-stats.mozilla.com/report/list?version=Firefox%3A15.0a1&range_value=14&range_unit=days&signature=xpc%3A%3AWrapperFactory%3A%3APrepareForWrapping%28JSContext*%2C%20JSObject*%2C%20JSObject*%2C%20unsigned%20int%29 Note that there was a 2012050403 build and a 2012050412 build on the same day, so the regression window might even be between those two. Here's the relevant data on those two builds and the nightly before it: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-04-12-29-39-mozilla-central/firefox-15.0a1.en-US.win32.txt 20120504122939 http://hg.mozilla.org/mozilla-central/rev/9ebf3dc839c5 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-04-03-05-09-mozilla-central/firefox-15.0a1.en-US.win32.txt 20120504030509 http://hg.mozilla.org/mozilla-central/rev/2db9df42823d http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-03-03-05-12-mozilla-central/firefox-15.0a1.en-US.win32.txt 20120503030512 http://hg.mozilla.org/mozilla-central/rev/807403a04a6a Given that, I'd concentrate on http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2db9df42823d&tochange=9ebf3dc839c5 for finding the regression, and if nothing jumps out, I'd look at http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=807403a04a6a&tochange=9ebf3dc839c5 as well, which is the full range between the nightly from the day before and the build that first shows the regression on crash-stats.
Alice, can you narrow down the regression range using the testcase?
Oh, this is definitely a CPG regression. I'm on it, over in bug 752038. Sorry for not making that more clear.
I also hit this crash when running the cross_fuzz DOM fuzzing test for 1-2 minutes: http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_msie_randomized_seed.html#956626056
This actually has two sources that I've discovered so far. One is bug 754311, the other is bug 754044. I've got patches for both, which I'll upload momentarily.
All of my latest crashes (using OSX 10.7.4) started with build ID 20120505030510, all of them seem related to this bug (and a DUP and a really old closed one). Maybe it could be useful for devs, my trigger is ZyngaPoker on Facebook. After playing some hands and using the chat Nightly crashes.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
The patches in the bugs mentioned in comment 13 landed, so I'm assuming the WFM means that they did the trick. \o/
I guess so, a recent trunk build doesn't exhibit this crash at least.
WFM. I tested Nightly 2012-05-16 and cross_fuzz no longer crashes. It used to crash within seconds.
(In reply to Bobby Holley (:bholley) from comment #15) > The patches in the bugs mentioned in comment 13 landed, so I'm assuming the > WFM means that they did the trick. \o/ Bobby - this signature is still showing up on the FF15.0a2 top crash list (https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/15.0a2/7). Are you sure bug 754044 fixed this crash?
Most of those crashes are from people on builds from 6/19 or earlier (almost 3 weeks old). Which suggests that maybe bug 754044 (which was fixed mid May) didn't do the trick, but it doesn't seem like there are more than a few crashes on recent builds.
[Triage comment] Untracking since the number of crashes is going down significantly and as Andrew says, there aren't many on recent builds.
You need to log in before you can comment on or make changes to this bug.