Closed
Bug 293534
Opened 20 years ago
Closed 20 years ago
reloading with bfcache will crash Camino (nsDocShell::RestorePresentation(nsISHEntry*, int, int*) + 0x72c)
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: torben, Assigned: bryner)
References
()
Details
(Keywords: crash)
Attachments
(3 files)
|
21.27 KB,
text/plain
|
Details | |
|
15.16 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
brendan
:
approval1.8b2+
|
Details | Diff | Splinter Review |
|
24.79 KB,
text/plain
|
Details |
Camino 2005050908 (v0.8+)
(Found when trying to reproduce bug 245026)
With bfcache enabled (browser.sessionhistory.max_viewers, 5) Camino will crash
when you try to reload the url. No crash with bfcache turned off. Curiously
Firefox (same build date) does _not_ crash with bfcache turned on.
Might, or might not, be related to bug 292969 and/or bug 292970.
Steps to reproduce:
1. Go to http://www.dioceseofstasaph.org.uk/
2. Click on a link to "Diocesesan organisations" in the left column
3. Click the reload button
Expected result:
Reload page
Actual result:
Crash
Trackback ID TB5704257M, crashlog coming up
Comment 2•20 years ago
|
||
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050510] (nightly) (W98SE)
Confirmation: MozillaAS doesn't crash at step 3 either.
(bug I can get bug 293698 going Back at a fourth step)
Updated•20 years ago
|
Severity: normal → critical
| Assignee | ||
Comment 3•20 years ago
|
||
The problem here happens as follows:
- The site contains a <frameset> with a single <frame>
- When you click a link in the frame, the session history tree is cloned; the
clone does not have any cached presentation. The original history tree (a
parent entry and one child) has cached content viewers for both the parent and
the child.
- When you reload, the <frame> and its corresponding docshell are destroyed.
The child history entry's viewer now has a dangling container pointer.
- Go to restore the child history entry -> crash
There are basically 3 things we can do:
- hold a strong reference to the docshell; swap it back into the docshell tree
when restoring the <frame>
- hold a weak reference; bail on restoring the presentation if the docshell has
gone away
- hold a weak reference; try to restore the presentation into the _new_
docshell if the docshell has gone away
I've opted to go for the second one. This might be worth revisiting if it
affects a significant number of sites / use cases, but the other options seem
pretty scary to me.
I originally wanted to do this just by making Open() fail, but it turns out
that we don't unhook the old content viewer correctly when that happens,
leading to crashes. I just added an up-front check that the container of the
stored content viewer is in fact the docshell we're restoring it to, which is a
good invariant even if having Open() fail worked as expected.
| Assignee | ||
Updated•20 years ago
|
Attachment #183352 -
Flags: superreview?(bzbarsky)
Attachment #183352 -
Flags: review?(bzbarsky)
| Assignee | ||
Comment 4•20 years ago
|
||
In addition to this:
+ if (container !=
nsCOMPtr<nsISupports>(do_QueryInterface(NS_STATIC_CAST(nsIDocShell*, this)))) {
+#ifdef DEBUG_PAGE_CACHE
+ printf("No valid container, not restoring presentation\n");
+#endif
+ return NS_OK;
+ }
I wonder if it would make sense to clear out the whole presentation on the
history entry...
FWIW, my Camino won't build with the above patch (attachment (id=183352))
nsDocShell.cpp: In member function `nsresult
nsDocShell::RestorePresentation(nsISHEntry*, int, PRBool*)':
nsDocShell.cpp:5180: error: `uri' undeclared (first use this function)
nsDocShell.cpp:5180: error: (Each undeclared identifier is reported only once
for each function it appears in.)
Comment 6•20 years ago
|
||
Comment on attachment 183352 [details] [diff] [review]
patch
>Index: docshell/base/nsDocShell.cpp
> #ifdef DEBUG_PAGE_CACHE
>+ nsCOMPtr<nsIURI> uri;
>+ aSHEntry->GetURI(getter_AddRefs(uri));
|uri| is passed to SetCurrentURI at the end of this method, so we can't move
getting it into this ifdef....
>@@ -4970,6 +4970,21 @@ nsDocShell::RestorePresentation(nsISHEnt
>+ if (container != nsCOMPtr<nsISupports>(do_QueryInterface(NS_STATIC_CAST(nsIDocShell*, this)))) {
I'd prefer:
if (!::SameCOMIdentity(container, GetAsSupports(this))) {
here.
And yes, clearing out the presentation on the history entry when we hit this
case makes a lot of sense to me.
>Index: layout/base/nsDocumentViewer.cpp
>@@ -610,10 +611,7 @@ DocumentViewerImpl::GetContainer(nsISupp
>+ return CallQueryReferent(mContainer.get(), aResult);
Won't that crash if mContainer is null (eg a container was never set)? Is that
something we should worry about? If so, may be worth using do_QueryReferent
and then swap() here.
>@@ -1466,13 +1471,19 @@ DocumentViewerImpl::SetDOMDocument(nsIDO
>+ nsCOMPtr<nsIScriptGlobalObject> global;
>+ if (requestor) {
>+ CallGetInterface(requestor.get(),
>+ NS_STATIC_CAST(nsIScriptGlobalObject**,
>+ getter_AddRefs(global)));
>+ }
Is this not using do_GetInterface(requestor); just to avoid an extra QI? If
so, I'd go with the extra QI and clearer code... but either way.
>@@ -4018,7 +4032,14 @@ DocumentViewerImpl::OnDonePrinting()
>+ nsCOMPtr<nsIDOMWindowInternal> win;
>+ if (requestor) {
>+ CallGetInterface(requestor.get(),
>+ NS_STATIC_CAST(nsIDOMWindowInternal**,
>+ getter_AddRefs(win)));
>+ }
Same here.
r+sr=bzbarsky with the nits picked.
Attachment #183352 -
Flags: superreview?(bzbarsky)
Attachment #183352 -
Flags: superreview+
Attachment #183352 -
Flags: review?(bzbarsky)
Attachment #183352 -
Flags: review+
Camino will still crash with this patch (after moving the definition of uri
outside the #ifdef or #ifdef'ing the SetCurrentURI) if after reloading the page
I click on the link to "Diocesesan organisations" again. The crash now happens
in nsChildView::Destroy().
| Assignee | ||
Comment 8•20 years ago
|
||
(In reply to comment #6)
> >@@ -1466,13 +1471,19 @@ DocumentViewerImpl::SetDOMDocument(nsIDO
> >+ nsCOMPtr<nsIScriptGlobalObject> global;
> >+ if (requestor) {
> >+ CallGetInterface(requestor.get(),
> >+ NS_STATIC_CAST(nsIScriptGlobalObject**,
> >+ getter_AddRefs(global)));
> >+ }
>
> Is this not using do_GetInterface(requestor); just to avoid an extra QI? If
> so, I'd go with the extra QI and clearer code... but either way.
>
Yep, trying to avoid the extra QI when we already have an nsIInterfaceRequestor.
I wonder if it would make more sense to add an overloaded do_GetInterface()
implementation for nsIInterfaceRequestor*.
| Assignee | ||
Comment 9•20 years ago
|
||
I'll do a Camino build this afternoon and try to figure out what's going on.
(In reply to comment #7)
> Created an attachment (id=183434) [edit]
> Crash log 2
>
> Camino will still crash with this patch (after moving the definition of uri
> outside the #ifdef or #ifdef'ing the SetCurrentURI) if after reloading the page
> I click on the link to "Diocesesan organisations" again. The crash now happens
> in nsChildView::Destroy().
| Assignee | ||
Comment 10•20 years ago
|
||
Comment on attachment 183352 [details] [diff] [review]
patch
I'm not seeing Camino crash using this patch. I did address Boris's comment
regarding possible crash with CallQueryReferent, so maybe that's the reason.
Either way, I'd like to get this in.
Attachment #183352 -
Flags: approval1.8b2?
Comment 11•20 years ago
|
||
Comment on attachment 183352 [details] [diff] [review]
patch
a=me with comments addressed.
/be
Attachment #183352 -
Flags: approval1.8b2? → approval1.8b2+
| Assignee | ||
Comment 12•20 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 13•20 years ago
|
||
crashed Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050514
I know this build doesn´t contain the patch, and I couldn´t reproduce the crash.
I´ve seen some sort of runtime error, didn´t care about text or number, as I
wanted to reproduce after enabling talkback by deleting compreg.dat.
| Reporter | ||
Comment 14•20 years ago
|
||
No more crashes for me either with the checked in patch.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in
before you can comment on or make changes to this bug.
Description
•