Closed Bug 303765 Opened 19 years ago Closed 19 years ago

Repeatable crash while manually refreshing Gmail during automatic refresh (XPCWrappedNative stuff)

Categories

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

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: samuel.sidler+old, Assigned: jst)

References

()

Details

(Keywords: crash, regression, verified1.8)

Attachments

(3 files)

I've been getting a crash over and over again while using Gmail. I'm currently
using a Camino nightly from August 4. This may be related to the split-window
check-in. The crash logs are as follows:

http://paste.lisp.org/display/10569
http://paste.lisp.org/display/10561
http://paste.lisp.org/display/10567
http://paste.lisp.org/display/10570

To reproduce:
1. Login to Gmail
2. Wait for Gmail to start it's auto-refresh, checking for new mail
3. Refresh manually by pressing command-R (as the menu button is disabled)

This has caused Camino to crash every time for me.

Related talkback IDs: TB8149149E, TB8153178H, TB8153304M, and TB8153343H.
Marking as regression/crash.
Keywords: crash, regression
Summary: Repeatable crash while manually refreshing Gmail during automatic refresh → Repeatable crash while manually refreshing Gmail during automatic refresh (XPCWrappedNative stuff)
Since this is a regression, requesting blocking1.8b4.
Flags: blocking1.8b4?
For the record, this does not occur in the DP nightlies. It seems it's probably
only a Camino/embeddeding issue, but it's definitely a core bug.
this should go on jst's split-window meta bug. anyone know what bug that is so
we can mark it as a blocker?
I don't get reproducable crashes on windows trunk, but I'm pretty sure this is
also noticable in windows. Talkback ID: TB8179912M
This is very easy to reproduce in Camino; just log into Gmail and refresh a few
times. Stack:

#1  0x019ffe80 in js_GetSlotThreadSafe ()
#2  0x019c9c1c in JS_GetClass ()
#3  0x00132e58 in GetScopeOfObject ()
#4  0x00132f30 in XPCWrappedNativeScope::FindInJSObjectScope ()
#5  0x00140a38 in XPCConvert::NativeInterface2JSObject ()
#6  0x001268f4 in nsXPConnect::WrapNative ()
#7  0x004e6ee8 in nsJSEventListener::HandleEvent ()
#8  0x00390e3c in nsEventListenerManager::HandleEventSubType ()
#9  0x00391180 in nsEventListenerManager::HandleEvent ()
#10 0x003ebf18 in nsGlobalWindow::HandleDOMEvent ()
#11 0x00349628 in DocumentViewerImpl::PageHide ()
#12 0x00222774 in nsDocShell::FirePageHideNotification ()
#13 0x0022280c in nsDocShell::FirePageHideNotification ()
#14 0x0022d160 in nsDocShell::CreateContentViewer ()
#15 0x00236ce0 in nsDSURIContentListener::DoContent ()
#16 0x0020e1b0 in nsDocumentOpenInfo::TryContentListener ()
#17 0x0020d7e0 in nsDocumentOpenInfo::DispatchContent ()
#18 0x0020d240 in nsDocumentOpenInfo::OnStartRequest ()
#19 0x000d4714 in nsHttpChannel::CallOnStartRequest ()
#20 0x000d4c50 in nsHttpChannel::ProcessNormal ()
#21 0x000d4a04 in nsHttpChannel::ProcessResponse ()
#22 0x000dcc60 in nsHttpChannel::OnStartRequest ()
#23 0x000b5ff0 in nsInputStreamPump::OnStateStart ()
#24 0x000b5f08 in nsInputStreamPump::OnInputStreamReady ()
#25 0x00f8dedc in nsInputStreamReadyEvent::EventHandler ()
#26 0x00f4f374 in PL_HandleEvent ()
#27 0x00f4f2a4 in PL_ProcessPendingEvents ()
#28 0x00f4f654 in _md_EventReceiverProc ()
#29 0x9074bd2c in __CFRunLoopDoSources0 ()
#30 0x9074b25c in __CFRunLoopRun ()
#31 0x9074acdc in CFRunLoopRunSpecific ()
#32 0x93123be0 in RunCurrentEventLoopInMode ()
#33 0x93123274 in ReceiveNextEventCommon ()
#34 0x931230e0 in BlockUntilNextEventMatchingListInMode ()
#35 0x9361e1a4 in _DPSNextEvent ()
#36 0x9361de68 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#37 0x9361a3cc in -[NSApplication run] ()
#38 0x9370ac1c in NSApplicationMain ()
#39 0x00002fa8 in _start (argc=2, argv=0xbffffd3c, envp=0xbffffd48) at
/SourceCache/Csu/Csu-45/crt.c:267
#40 0x00002e28 in start ()
Priority: -- → P1
I managed to crash DP too, by refreshing gmail a bunch of times, and then
closing the window.
Just before I crashed, I got 6 of these:
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
../../../../mozilla/layout/base/nsPresShell.cpp, line 7146

which is from

      rv = loadGroup->RemoveRequest(mDummyLayoutRequest, nsnull, NS_OK);
      NS_ENSURE_SUCCESS(rv, rv);

in PresShell::RemoveDummyLayoutRequest().
Happens even with
user_pref("browser.sessionhistory.max_viewers", 0);
It looks like we're handling an event for an nsGlobalWindow that has been
deleted. The wrapped object is an nsGlobalWindow, and if I log their dtors, this
particular one was deleted earlier.
Assignee: general → jst
I should note that once I crashed with
Reason: KERN_INVALID_ADDRESS at address: 0x20202020
which sure looks like text. That could make this an attack vector.
Flags: blocking1.8b4? → blocking1.8b4+
(In reply to comment #12)
> I should note that once I crashed with
> Reason: KERN_INVALID_ADDRESS at address: 0x20202020
> which sure looks like text. That could make this an attack vector.

No, those look like JS gc-thing-flag finalized object tombstones (we generally
don't store ASCII, but if you saw other than 0x20 that was a likely word char or
punctuation char, I'd be interested).  Who knows whether this is exploitable;
I'm convinced most heap overruns that can be triggered from content are, with
enough work.

So split window changed window object ownership rules, but followed them in the
non-embedding case used by Firefox, Thunderbird, etc.  But what differs in the
embedding case used by Camino?

Something is not rooting a JSObject properly.  If you can get the window object
address to replay from run to run, then by adding a conditional breakpoint or
hacking something equivalent into the code, a Camino developer could show the
stack of the GC that finalized this window object.  That should help, although
we would then have to reason or debug further to figure out how that object came
to be unrooted.

/be
Does this change to nsGlobalWindow::nsGlobalWindow(...) make any difference here:

-    PR_INSERT_AFTER(aOuterWindow, this);
+    PR_INSERT_AFTER(this, aOuterWindow);

?
(In reply to comment #14)
> Does this change to nsGlobalWindow::nsGlobalWindow(...) make any difference here:
> 
> -    PR_INSERT_AFTER(aOuterWindow, this);
> +    PR_INSERT_AFTER(this, aOuterWindow);

Nope, still crashes in the same way.
Simon, try to find me on IRC when you get this in a debugger and I'll help.  Use
#content if you like, I'm there when I am on and not idle/afk/away.

/be
Attached patch Fix.Splinter Review
As I have yet to see this crash happen myself I can't say for sure if this does
indeed fix this, but it seems like the likely problem. We could end up reusing
the listener manager on more than one inner window, which is simply not safe to
do (nor correct). This fixes that problem, please test to see if it fixes this
crash as well.
Comment on attachment 192953 [details] [diff] [review]
Fix.

The patch does indeed fix the crash, and I see the listener managers and event
listeners getting destroyed correctly.
Attachment #192953 - Flags: review+
So that will preserve event listeners if and only if we're preserving the entire
inner window?  And we do that for the leaving about:blank case?
(In reply to comment #19)
> So that will preserve event listeners if and only if we're preserving the entire
> inner window?  And we do that for the leaving about:blank case?

Indeed. This still needs more testing, but that's the intent here...
I believe I've tested what I can think of to test here, so this patch should be
good to go.
Blocks: splitwindows
No longer depends on: splitwindows
Attachment #192953 - Attachment description: Possible fix. → Fix.
Attachment #192953 - Flags: superreview?(brendan)
Comment on attachment 192953 [details] [diff] [review]
Fix.

sr+a=me.

/be
Attachment #192953 - Flags: superreview?(brendan)
Attachment #192953 - Flags: superreview+
Attachment #192953 - Flags: approval1.8b4+
Fixed on trunk and branch.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Looks good using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b5) Gecko/20050928 Firefox/1.4. Hitting Command-R a bunch of times does
not result in a crash. Adding verified keyword.
Keywords: fixed1.8verified1.8
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: