Closed Bug 125713 Opened 24 years ago Closed 24 years ago

Trunk Crashes clicking thru mail in thread pane [@ nsPresContext::LoadImage]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: timeless, Assigned: pavlov)

References

Details

(Keywords: assertion, crash, topcrash)

Crash Data

Attachments

(1 file)

Fix
1.68 KB, patch
mozilla
: review+
brendan
: superreview+
Details | Diff | Splinter Review
freebsd cvs build from yesterday/today. i have one patch the drops large images. #0 0x29f6bf2b in nsPresContext::LoadImage (this=0x8f6bc00, aURL=@0x90de104, aTargetFrame=0x90de060, aRequest=0xbfbfde38) at /home/timeless/mozilla/layout/base/src/nsPresContext.cpp:1511 #1 0x29ea7503 in nsCSSRendering::PaintBackgroundWithSC (aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aForFrame=0x90de060, aDirtyRect=@0xbfbfe098, aBorderArea=@0xbfbfe008, aColor=@0x90de0f4, aBorder=@0x90ef238, aDX=0, aDY=0) at /home/timeless/mozilla/layout/html/style/src/nsCSSRendering.cpp:2675 #2 0x29ea6ac2 in nsCSSRendering::PaintBackground (aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aForFrame=0x90de060, aDirtyRect=@0xbfbfe098, aBorderArea=@0xbfbfe008, aBorder=@0x90ef238, aDX=0, aDY=0) at /home/timeless/mozilla/layout/html/style/src/nsCSSRendering.cpp:2528 #3 0x29f1fa06 in nsBoxFrame::Paint (this=0x90de060, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe098, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1590 #4 0x29f1fead in nsBoxFrame::PaintChild (this=0x90bf47c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe458, aFrame=0x90de060, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1679 #5 0x29f20839 in nsBoxFrame::PaintChildren (this=0x90bf47c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe458, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1816 #6 0x29f1fd13 in nsBoxFrame::Paint (this=0x90bf47c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe458, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1631 #7 0x29f1fead in nsBoxFrame::PaintChild (this=0x90bf16c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe818, aFrame=0x90bf47c, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1679 #8 0x29f20839 in nsBoxFrame::PaintChildren (this=0x90bf16c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe818, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1816 #9 0x29f1fd13 in nsBoxFrame::Paint (this=0x90bf16c, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfe818, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/xul/base/src/nsBoxFrame.cpp:1631 #10 0x29d91c03 in nsContainerFrame::PaintChild (this=0x90bf130, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfea7c, aFrame=0x90bf16c, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/html/base/src/nsContainerFrame.cpp:252 #11 0x29d91a69 in nsContainerFrame::PaintChildren (this=0x90bf130, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfea7c, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/html/base/src/nsContainerFrame.cpp:196 #12 0x29d919f1 in nsContainerFrame::Paint (this=0x90bf130, aPresContext=0x8f6bc00, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfea7c, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at /home/timeless/mozilla/layout/html/base/src/nsContainerFrame.cpp:177 #13 0x29e00cc6 in PresShell::Paint (this=0x900b000, aView=0x8db0500, aRenderingContext=@0x910d000, aDirtyRect=@0xbfbfea7c) at /home/timeless/mozilla/layout/html/base/src/nsPresShell.cpp:5710 #14 0x2a18f1d4 in nsView::Paint (this=0x8db0500, rc=@0x910d000, rect=@0xbfbfea7c, aPaintFlags=0, aResult=@0xbfbfeaa8) at /home/timeless/mozilla/view/src/nsView.cpp:273 #15 0x2a19c077 in nsViewManager::RenderDisplayListElement (this=0x8f01c00, element=0x8b1ff80, aRC=@0x910d000) at /home/timeless/mozilla/view/src/nsViewManager.cpp:1174 #16 0x2a19be4c in nsViewManager::RenderViews (this=0x8f01c00, aRootView=0x8db0500, aRC=@0x910d000, aRect=@0xbfbfecd0, aResult=@0xbfbfed28) at /home/timeless/mozilla/view/src/nsViewManager.cpp:1122 #17 0x2a19a5cb in nsViewManager::Refresh (this=0x8f01c00, aView=0x8db0500, aContext=0x910d000, aRegion=0x8897bb0, aUpdateFlags=1) at /home/timeless/mozilla/view/src/nsViewManager.cpp:722 #18 0x2a19dcaf in nsViewManager::DispatchEvent (this=0x8f01c00, aEvent=0xbfbff054, aStatus=0xbfbfee9c) at /home/timeless/mozilla/view/src/nsViewManager.cpp:1694 #19 0x2a18e90a in HandleEvent (aEvent=0xbfbff054) at /home/timeless/mozilla/view/src/nsView.cpp:80 #20 0x295df2b8 in nsWidget::DispatchEvent (this=0x8ff4600, aEvent=0xbfbff054, aStatus=@0xbfbfef8c) at /home/timeless/mozilla/widget/src/gtk/nsWidget.cpp:1376 #21 0x295dee49 in nsWidget::DispatchWindowEvent (this=0x8ff4600, event=0xbfbff054) at /home/timeless/mozilla/widget/src/gtk/nsWidget.cpp:1264 #22 0x295e4c50 in nsWindow::DoPaint (this=0x8ff4600, aX=0, aY=0, aWidth=591, aHeight=691, aClipRegion=0x8c1dd20) at /home/timeless/mozilla/widget/src/gtk/nsWindow.cpp:759 #23 0x295e4fd2 in nsWindow::Update (this=0x8ff4600) at /home/timeless/mozilla/widget/src/gtk/nsWindow.cpp:805 #24 0x295e4824 in nsWindow::UpdateIdle (data=0x0) at /home/timeless/mozilla/widget/src/gtk/nsWindow.cpp:668 #25 0x28552d26 in g_idle_dispatch () from /usr/local/lib/libglib12.so.3 #26 0x28551d03 in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #27 0x2855232c in g_main_iterate () from /usr/local/lib/libglib12.so.3 ---Type <return> to continue, or q <return> to quit--- #28 0x285524c4 in g_main_run () from /usr/local/lib/libglib12.so.3 #29 0x284728b7 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #30 0x295cbe39 in nsAppShell::Run (this=0x813b600) at /home/timeless/mozilla/widget/src/gtk/nsAppShell.cpp:364 #31 0x2955dd09 in nsAppShellService::Run (this=0x810b280) at /home/timeless/mozilla/xpfe/appshell/src/nsAppShellService.cpp:307 #32 0x0805ab78 in main1 (argc=4, argv=0xbfbff5e4, nativeApp=0x0) at /home/timeless/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1285 #33 0x0805b8d9 in main (argc=4, argv=0xbfbff5e4) at /home/timeless/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1625 #34 0x08055c2d in _start () (gdb) l 1506 nsCOMPtr<nsIDocument> document; 1507 rv = content->GetDocument(*getter_AddRefs(document)); 1508 if (NS_FAILED(rv)) return rv; 1509 1510 nsCOMPtr<nsIScriptGlobalObject> globalScript; 1511 rv = document->GetScriptGlobalObject(getter_AddRefs(globalScript)); 1512 if (NS_FAILED(rv)) return rv; 1513 1514 nsCOMPtr<nsIDOMWindow> domWin(do_QueryInterface(globalScript)); 1515 (gdb) p document $1 = {mRawPtr = 0x0} (gdb) p rv $2 = 0 (gdb) p content $3 = {mRawPtr = 0x90cfac0} my guess is that the GetDocument call on 1507 rv = content->GetDocument(*getter_AddRefs(document)); is incorrectly implemented.
Need URL or testcase
Target Milestone: --- → mozilla1.1
seek sr: Bug 120348 - crash in macro CCMAP... Shanjian Li 02/06/02 15:03 npm.reviewers I can't easily get a url for this. I do crash right after the assert. give the stack can you suggest what variables would be useful for me to provide or how i might find something useful? I can do debugging here.
Keywords: assertion, crash
this is in the code I checked in last night. taking
Assignee: attinasi → pavlov
Target Milestone: mozilla1.1 → mozilla0.9.9
FWIW I got this in my debug build as well. From what I saw, it's caused because content->GetDocument doesn't return an error when it returns a null pointer. I'm not sure that nsXULElement::GetDocument's implementation is incorrect in that respect. At least it has a lot of company. I think LoadImage needs to test the pointer for null and then bail.
Attached patch Fix — — Splinter Review
Here's a patch that will just skip the policy checks if things fail.
Changing QA contact
QA Contact: petersen → amar
*** Bug 125814 has been marked as a duplicate of this bug. ***
need r= and sr=
Status: NEW → ASSIGNED
Summary: ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0' → Trunk Crashes clicking thru mail in thread pane [@ nsPresContext::LoadImage]
The |content| null check that this whole block is in is pointless, and the |document| is going to be null frequently, during destruction, which to some point defeats the point of the policy. (But if it's during destruction, maybe we should just not bother kicking off the image load, as if the policy rejected it?)
perhaps, but are we sure that is the only time when the document will be null?
I think the only times GetDocument should return null is if: * the content node is not in a document * the document is being destroyed. jst?
Yep, the document should not be null in any other cases. Any time there is a frame for an image (or any element) the document should be non-null.
*** Bug 126084 has been marked as a duplicate of this bug. ***
OS: FreeBSD → All
Hardware: PC → All
*** Bug 126033 has been marked as a duplicate of this bug. ***
another potential fix: rv = content->GetDocument(*getter_AddRefs(document)); - if (NS_FAILED(rv)) return rv; + if (NS_FAILED(rv) || !document) return rv;
Keywords: nsbeta1
whoops, ignore that patch. I didn't realize pavlov, jst and dbaron were already on the case.
*** Bug 126227 has been marked as a duplicate of this bug. ***
An easily reproducible case for this is switching quickly between the Fonts and Appearance pref panels.
Copying the topcrash KW from duped bug 125814 for talkback tracking. This one is currently #1 on the Trunk.
Keywords: topcrash
If you are still looking for a testcase, I got this while getting a message list for n.p.m.seamonkey (bug #126084). That is, use Mozilla's newsreader and try to read newsgroups (mind you, after n.p.m.seamonkey, I didn't want to try any other newsgroups).
*** Bug 126257 has been marked as a duplicate of this bug. ***
*** Bug 126229 has been marked as a duplicate of this bug. ***
This pretty much blocks chatzilla, at least on my system now.
*** Bug 125839 has been marked as a duplicate of this bug. ***
Blocks: 122050
Comment on attachment 69740 [details] [diff] [review] Fix The old null document problem, eh? sr=me. /be
Attachment #69740 - Flags: superreview+
Comment on attachment 69740 [details] [diff] [review] Fix r=jgaunt
Attachment #69740 - Flags: review+
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 126086 has been marked as a duplicate of this bug. ***
*** Bug 126625 has been marked as a duplicate of this bug. ***
*** Bug 126561 has been marked as a duplicate of this bug. ***
*** Bug 126305 has been marked as a duplicate of this bug. ***
*** Bug 127057 has been marked as a duplicate of this bug. ***
This seems to be fixed using the builds since late yeterday (2002-20-20).
reopening bug, based on http://ftp.mozilla.org/pub/data/crash-data/rankoutput.html this is still the number one crasher in current builds All talback reports seem to say OS: Windows NT 5.0 build 2195 Look at http://ftp.mozilla.org/pub/data/crash-data/detailed-crash-analysis-all.html#nsPresContext::LoadImage for recent stacktraces and Talkback IDs
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I don't see anything on the details page for a build made after this patch was checked in.
rankoutput.html shows build 20020225 as number one crasher which is certainly after the checkin According to Stuart Parmenter "fix checked in" 2002-02-19 23:51 but: http://ftp.mozilla.org/pub/data/crash-data/detailed-crash-analysis-all.html#nsPresContext::LoadImage shows just below the stacktrace: "http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsPresContext.cpp line no: 1512 Build: 2002021506 CrashDate: 2002-02-15 OS: Windows NT 5.0..." which is certainly after the fix was checked in
Man, I am dumb but should be able to group some numbers in pairs, right? The details page indeed doesn't show any newer builds, you are right, but the ranking page shows it still as number one crasher, which is why I reopened it...
I'm pretty sure this is fixed, but I understand why Sebastian might have been misled by the rank table. Although it appears to rank the crashes by build id, it's simply the number of topcrashers reported up to that date (during the last 10 days). That's why this crash still seems to be the "#1" crash... A better table to look at to verify if a crash is still around or not is: http://warp/u/talkback/reports/Trunk/Trunk-topcrashers.html That table actually shows the numbers of topcrashers by build date. It hasn't been updated since 2/18 builds...but when it is, we shouldn't see any crashes for dates after the fix went in. Leaving it reopen until we can verify that.
this is fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Verified on Build Id: 2002041003.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsPresContext::LoadImage]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: