If you set your preferences to allow images but to ask before loading each one, and then visit a page you have never visited before which has multiple images, and on the first few "allow this image" dialogs the "remember this decision" box is NOT CHECKED, and then after allowing or disallowing a few images you check the boc and allow or disallow, mozilla will crash. Same applies for cookies. Steps to reproduce: 1.Set preferences to allow all images but to ask you before each one. 2.Go to a page with lots of images -- http://cagle.slate.msn.com/ will work 3. When the first "load this image" dialog comes up, be sure to not click the "remeber this decision" box, and the allow it (or disallow, doesn't matter) 4. Continue to approve or disapprove an image at a time for at least three more images 5. On one of the allow image dialogs, now click "remember this decision", and allow or disallow the image 6. Scream in horror and go into the fetal curl / testicular clutch position as you witness . . . . A mozilla crash ! Actual Results: Mozilla crashed. After several minutes of shivering and whimpering, I managed to uncurl and crawl back to my desk, where I managed to let go of my testicles with one hand long enough to post this message. Expected results: Mozilla should reload the rest of the page without querying me about whether to load images or not, just loading and displaying the page. If some images were allowed to load and not others, they should or shouldn't be there accordingly, regardless of the final set-in-stone allow or disallow decision. No fetal curling, testical clutching, or screaming like a little girl is necessary. Additional Information: Replace "images" with "cookies", it still crashes. I don't have a good example of a page that loads tons of cookies off hand. Sometimes mozilla pops up more than one image/cookie dialog at once, and if you give two different answers to the "remember this decision" box, you crash. I think this will even happen if the two allow images/cookies dialogs are asking about different sites, but not sure on that detail. I have submitted numerous talkbacks from this bug. Is there any point to submitting talkbacks ? This bug might be related to bug 88559, I think someone's comments in there discribed this bug. This bug is very old. I think I have occasionally seen it for more than a year. It just recently happened that I cleaned out all my image blocking preferences and started re-building the black list, so I've been seeing it a lot lately.

Hmm. I can't reproduce this crash on win2k or Linux (current tip trunk builds). But, yes, talkback is very much looked at (there are people here who do nothing but look at talkback data). Please attach some of the bug id numbers that you have for this crash. [On Linux, run the program <install-directory>/components/talkback/talkback to bring up a dialog which will show previously submitted Talkback reports].

Easily reproduced on a current CVS, Linux. Resembles the stack in bug 128282.

-> imagelib

might add... i managed to crash at sites i visit frequently, and i've *never* had problems there before. But i've never used the image blocking (nor cookie blocking) feture before today either.

looks a lot like bug 126092

Many thanks to John Morrison for showing me how to get to my talkbacks. Here are the four talkbacks that were in my history: TB3587152M TB3574285X TB3530469E TB3529998G I will keep using talkback, since someone reads them - thanks. R.K.Aa said that it resembled bug 128282, but when I looked at the page refered to in that bug -- gabber.sourceforge.net -- mozilla didn't crash. It ask me twice if I wanted to allow image loading, even though the "always" box was clicked the first time, but after that it loaded fine. Andrew Schultz said that it might be related to bug 126092, and I looked at that bug and replicated it -- but that still might be a different problem, because that crashed mozilla after asking to load the images once, not multiple image dialogs which is the usual thing I observe. Talkback: TB3589145W However in the comments attached to bug 126092 Andrew refered to bug 57188, which I think might be the same thing as this one.

i noticed first time i crashed that moz spawend one confirmation dialog "too many". One it was impossible to dismiss, it was "locked" behind the dismissable ones all the time. It vanished along with the last i managed to dismiss. As i thought i had verified all there was to verify (no more dialogs appeared) - page remained white for a sec - and then the crash. That was at the URL in this bug. The stack was from a second attempt; same procedures causing a crash at http://www.digi.no

Really annoying. I just started using the image blocking feature and keep crashing all over the place. My TBs: TB3655961Q TB3658284Z TB3675217Y

stephend, do the talkback stacks match the one in comment 3?

nsImageGTK::Draw() nsRenderingContextImpl::DrawImage() nsRenderingContextGTK::DrawImage() nsImageFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableCellFrame::Paint() nsTableRowFrame::PaintChildren() nsTableRowFrame::Paint() nsTableRowGroupFrame::PaintChildren() nsTableRowGroupFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableFrame::PaintChildren() nsTableFrame::Paint() nsContainerFrame::PaintChild() nsTableOuterFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintFloaters() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableCellFrame::Paint() nsTableRowFrame::PaintChildren() nsTableRowFrame::Paint() nsTableRowGroupFrame::PaintChildren() nsTableRowGroupFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableFrame::PaintChildren() nsTableFrame::Paint() nsContainerFrame::PaintChild() nsTableOuterFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableCellFrame::Paint() nsTableRowFrame::PaintChildren() nsTableRowFrame::Paint() nsTableRowGroupFrame::PaintChildren() nsTableRowGroupFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableFrame::PaintChildren() nsTableFrame::Paint() nsContainerFrame::PaintChild() nsTableOuterFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsHTMLContainerFrame::Paint() CanvasFrame::Paint() PresShell::Paint() nsView::Paint() nsViewManager::RenderDisplayListElement() nsViewManager::RenderViews() nsViewManager::Refresh() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWindow::DoPaint() nsWindow::Update() nsWindow::Update() nsWindow::UpdateIdle() libglib-1.2.so.0 + 0x114fa (0x4037b4fa) libglib-1.2.so.0 + 0x104d8 (0x4037a4d8) libglib-1.2.so.0 + 0x10ae3 (0x4037aae3) libglib-1.2.so.0 + 0x10c7c (0x4037ac7c) libgtk-1.2.so.0 + 0x8d7f7 (0x4029b7f7) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x1d6cf (0x404be6cf)

I reproduced this with build 2002031913. The talkback is TB4525665Y. It had not happened for several weeks and I was hopeful it was gone, but it is still there.

Most of the crashes mentioned here look like bug 133633...but I wasn't sure which bug to mark a dup.

*** Bug 134558 has been marked as a duplicate of this bug. ***

since this only happens with image blocking turned on, over to morse.

Seeing this on FreeBSD too. The actual backtrace differs from invocation to invocation, as does the number of dialogs that need to be dismissed for the bug to trigger. I've seen the final crash happen in XDrawString as well as in XFillArc, FWIW. All of the data elements in the stack dumps I've collected are accessible from GDB, so no obvious data corruption on the stack. On my own build, the last output before the crash is: WEBSHELL+ = 6 WARNING: DropTimeout proceeding without context., file nsGlobalWindow.cpp, line 4559 WEBSHELL- = 5 we don't handle eBorderStyle_close yet... please fix me WEBSHELL+ = 6 we don't handle eBorderStyle_close yet... please fix me WEBSHELL+ = 7 WARNING: DropTimeout proceeding without context., file nsGlobalWindow.cpp, line 4559 WEBSHELL- = 6 ... and then a SEGV shuts down the party. I can easily reproduce it by unchecking "remember" and going to CNN.com, and clicking "No" for each confirmation. In normal use, it will happen once a day. I've got one run which crashed not in X or GTK, but in Mozilla proper: #0 0x28f2792d in nsRenderingContextGTK::my_gdk_draw_text (drawable=0x4, font=0x8548040, gc=0x85dec10, x=0, y=15, text=0xbfbfa4c0 "Welcome! \026\r*Ô¤¿¿Ðª¿¿ï\fp(°.\r\bÀ§\225\bP\2012)ï\fp(°.\r\b¬7>(p~8()\fp(\004´t(¬7>(", text_length=13) at nsRenderingContextGTK.cpp:2069 #1 0x28f03f57 in nsXFontNormal::DrawText8 (this=0x8929f60, aDrawable=0x4, aGC=0x85dec10, aX=0, aY=15, aString=0xbfbfa4c0 "Welcome! \026\r*Ô¤¿¿Ðª¿¿ï\fp(°.\r\bÀ§\225\bP\2012)ï\fp(°.\r\b¬7>(p~8()\fp(\004´t(¬7>(", aLength=13) at nsXFontNormal.cpp:51 #2 0x28f26018 in nsRenderingContextGTK::DrawString (this=0x88f9800, aString=0xbfbfa4c0 "Welcome! \026\r*Ô¤¿¿Ðª¿¿ï\fp(°.\r\bÀ§\225\bP\2012)ï\fp(°.\r\b¬7>(p~8()\fp(\004´t(¬7>(", aLength=13, aX=0, aY=152, aSpacing=0x0) at nsRenderingContextGTK.cpp:1536 #3 0x29d87bdf in nsTextFrame::PaintAsciiText (this=0x8918af0, aPresContext=0x883a000, aRenderingContext=@0x88f9800, aStyleContext=0x8918abc, aTextStyle=@0xbfbfa9bc, dx=0, dy=0) at nsTextFrame.cpp:3213 #4 0x29d818a4 in nsTextFrame::Paint (this=0x8918af0, aPresContext=0x883a000, aRenderingContext=@0x88f9800, aDirtyRect=@0xbfbfaa7c, aWhichLayer=eFramePaintLayer_Overlay, aFlags=0) at nsTextFrame.cpp:1489 This one seems to point to the "drawable" in nsRenderingContextGTK to become corrupted somehow. I've kept the core and the build tree in case anyone wants me to provide more detailed info. FreeBSD 4.5, 1.0-RC1 built from source tarball using just ./configure.

Okay, I'm fairly confident I've found what causes the crash. mOffScreenSurface is conditionally set to mSurface, but is unconditionally freed here: NS_IF_RELEASE(mOffscreenSurface); NS_IF_RELEASE(mFontMetrics); NS_IF_RELEASE(mContext); (around line 108 of nsRenderingContextGTK.cpp). If I take the NS_IF_RELEASE(mOffscreenSurface) out, it becomes rock solid (but of course, that may introduce a leak... and I didn't test *real* hard). Test procedure: enable "ask permission for images". Go to www.cnn.com. Click "no" for every image rapidly until you're blue in the face (after unchecking "remember" once). With the NS_IF_RELEASE in, it'll crash after just a few dialogs. Without, it survives www.cnn.com (and my index finger hurts from dismissing that many dialogs).

Marking dup of bug 133633, please reopen if you disagree. *** This bug has been marked as a duplicate of 133633 ***