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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: samuel.sidler+old, Assigned: jst)
References
()
Details
(Keywords: crash, regression, verified1.8)
Attachments
(3 files)
35.29 KB,
text/plain
|
Details | |
35.29 KB,
text/plain
|
Details | |
2.55 KB,
patch
|
sfraser_bugs
:
review+
brendan
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Updated•19 years ago
|
Summary: Repeatable crash while manually refreshing Gmail during automatic refresh → Repeatable crash while manually refreshing Gmail during automatic refresh (XPCWrappedNative stuff)
Reporter | ||
Comment 2•19 years ago
|
||
Since this is a regression, requesting blocking1.8b4.
Flags: blocking1.8b4?
Reporter | ||
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
this should go on jst's split-window meta bug. anyone know what bug that is so we can mark it as a blocker?
Updated•19 years ago
|
Depends on: splitwindows
Comment 5•19 years ago
|
||
I don't get reproducable crashes on windows trunk, but I'm pretty sure this is also noticable in windows. Talkback ID: TB8179912M
Comment 6•19 years ago
|
||
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
Comment 7•19 years ago
|
||
I managed to crash DP too, by refreshing gmail a bunch of times, and then closing the window.
Comment 8•19 years ago
|
||
Comment 9•19 years ago
|
||
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().
Comment 10•19 years ago
|
||
Happens even with user_pref("browser.sessionhistory.max_viewers", 0);
Comment 11•19 years ago
|
||
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
Comment 12•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Comment 13•19 years ago
|
||
(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
Assignee | ||
Comment 14•19 years ago
|
||
Does this change to nsGlobalWindow::nsGlobalWindow(...) make any difference here: - PR_INSERT_AFTER(aOuterWindow, this); + PR_INSERT_AFTER(this, aOuterWindow); ?
Comment 15•19 years ago
|
||
(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.
Comment 16•19 years ago
|
||
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
Assignee | ||
Comment 17•19 years ago
|
||
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 18•19 years ago
|
||
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+
Comment 19•19 years ago
|
||
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?
Assignee | ||
Comment 20•19 years ago
|
||
(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...
Assignee | ||
Comment 21•19 years ago
|
||
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
Assignee | ||
Updated•19 years ago
|
Attachment #192953 -
Attachment description: Possible fix. → Fix.
Attachment #192953 -
Flags: superreview?(brendan)
Comment 22•19 years ago
|
||
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+
Assignee | ||
Comment 23•19 years ago
|
||
Fixed on trunk and branch.
Comment 24•19 years ago
|
||
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.8 → verified1.8
Reporter | ||
Updated•17 years ago
|
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•