Closed Bug 348990 Opened 14 years ago Closed 13 years ago

[FIX]Crash [@ nsDOMClassInfo::PreCreate] when loading gmail, suddenly going offline while loading and pressing reload a few times

Categories

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

1.8 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: martijn.martijn, Assigned: bzbarsky)

References

()

Details

(5 keywords)

Crash Data

Attachments

(2 files)

I am able to crash Mozilla pretty reliably when I am loading GMail and suddenly going offline.
I can reproduce it on 1.8.0.x, 1.8.1 and trunk branch.
But it only happens in combination with the livehttp headers extension:
http://livehttpheaders.mozdev.org/installation.html

To reproduce:
- Install live http headers extension, restart
- Load gmail.com (you need to have an account an be logged in)
- Suddenly go offline (by using File->Work Offline)
- Press reload a couple of times

Result:
crash

It seems to be timing dependant. It seems you need to go offline when the back button gets activated (when you are able to press back).

Talkback ID: TB22184979X
nsDOMClassInfo::PreCreate   XPCWrappedNative::GetNewOrUsed   XPCConvert::NativeInterface2JSObject   XPCConvert::NativeData2JS   XPCWrappedNative::CallMethod  

This might very well be the same bug as bug 323641. Marking a dependancy on that bug.
Better way to reproduce (you still need Live http headers installed):
- Load Gmail
- Go offline
- Press the back button
- Press reload a couple of times
From talkback ID: 22767488
Tryed to download FlashFxp from download.com. Reproducible: always. click on the "download now" link:
http://www.download.com/FlashFXP/3000-2160-10037696.html?part=dl-FlashFXP&subj=dl&tag=button
Indeed, this always crashes for me when clicking on the download now link, so this is a much more reliable way of crashing with the livehttpheaders extension.
Was this a regression shortly before you filed it?  I see nsDOMClassInfo::PreCreate crashes starting to appear in Firefox2 (1.8 branch) talkback on 2006-08-08 (although at an average rate around 1 per day, so hard to tell exactly).

The user comments and the stack signature below the top seem a bit similar to bug 317283.
(In reply to comment #3)
> Was this a regression shortly before you filed it?  
Yeah, apparently it is (although 1.8.7pre branch also crashes for me).
The regression range I get for both trunk and 1.8 branch is between 2006-07-27 and 2006-07-28.
Bonsai link trunk:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-27+05&maxdate=2006-07-28+06&cvsroot=%2Fcvsroot
Bonsai link 1.8 branch:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-27+06&maxdate=2006-07-28+06&cvsroot=%2Fcvsroot

The patch for bug 345991 was checked in that day on 1.8 branch and on trunk. The patch was also checked in on 1.8.0.x branch, so that could explain why my 1.8.0.7pre (2006-08-24) branch build is also crashing.
I'm adding topcrash, although it's a little borderline for "top".
Keywords: topcrash
I just verified in my debug trunk build that backing out the patch from bug 345991 does fix the crash.
Blocks: 345991
Too late for 1.5.0.7, but nominating for 1.5.0.8 and adding regression keyword.  Let's try to get a handle on this for the next release.  Backing out bug 345991 has been suggested, but I wonder if there is a better way...

If people think this is a common enough case, we could relnote it.
Flags: blocking1.8.0.8?
Keywords: regression
Jay, this is a topcrash regression on the 1.8.0.x branch.  In my opinion we should hold 1.8.0.7 for fixing this one way or another; worst-case we do back out bug 345991.  I plan to spend tonight working on this in hopes of finding something better.

Note that I think that unlike security fixes for old problems (which I can understand slipping to the next security release if we want to release on a regular cycle), regressions should NOT get slipped once found; otherwise people will be afraid to update to the security releases we make...
Flags: blocking1.8.0.7?
Probably not really a topcrash -- it's 42 crashes across 14 users in Firefox2 nightlies (including the Fx2b2 release, although only a few there; most of the spike in nightlies has been since then).
Blocks: 323641
No longer depends on: 323641
Boris, I can't see any [@ nsDOMClassInfo::PreCreate] crashes listed at the firefox 1.5.0.6 talkback analysis page:
http://talkback-public.mozilla.org/reports/firefox/FF1506/index.html
Attached patch Proposed fixSplinter Review
This fixes the bug for me.  When splitwindow landed, there was code added to ensure inner windows for gets.  This code wasn't on for XPCNativeWrappers, however.  All this patch does is give XPCNativeWrapper parity with the raw Window object in terms of whether we force creation of an inner.  We continue to not forward the get to the inner in the XPCNativeWrapper case.

This fixes bug 323641 (where we always had an XPCNativeWrapper because we were performing a content access from chrome) and this bug (where we started getting an XPCNativeWrapper because of bug 345991).
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #237036 - Flags: superreview?(jst)
Attachment #237036 - Flags: review?(jst)
Flags: blocking1.8.1?
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: Crash [@ nsDOMClassInfo::PreCreate] when loading gmail, suddenly going offline while loading and pressing reload a few times → [FIX]Crash [@ nsDOMClassInfo::PreCreate] when loading gmail, suddenly going offline while loading and pressing reload a few times
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 237036 [details] [diff] [review]
Proposed fix

r+sr=jst
Attachment #237036 - Flags: superreview?(jst)
Attachment #237036 - Flags: superreview+
Attachment #237036 - Flags: review?(jst)
Attachment #237036 - Flags: review+
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 237036 [details] [diff] [review]
Proposed fix

Requesting branch approvals.  I think this should be quite safe.
Attachment #237036 - Flags: approval1.8.1?
Attachment #237036 - Flags: approval1.8.0.7?
Comment on attachment 237036 [details] [diff] [review]
Proposed fix

Approved for 1.8.0 branch, a=jay for drivers.  Please land this ASAP.
Attachment #237036 - Flags: approval1.8.0.7? → approval1.8.0.7+
Flags: blocking1.8.0.8?
Flags: blocking1.8.0.7?
Flags: blocking1.8.0.7+
Fixed on the 1.8.0 branch for 1.8.0.7.  Thanks for the speedy reviews and approvals!
Keywords: fixed1.8.0.7
Flags: blocking1.8.1? → blocking1.8.1+
Comment on attachment 237036 [details] [diff] [review]
Proposed fix

a=beltzner on behalf of 181drivers
Attachment #237036 - Flags: approval1.8.1? → approval1.8.1+
Fixed on 1.8.1 branch.
Keywords: fixed1.8.1
Flags: in-testsuite?
Crash Signature: [@ nsDOMClassInfo::PreCreate]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.