128677 - crash if you select "remember this decision" on allow image dialog in middle of page load (in image tiling code)

Status: RESOLVED DUPLICATE of bug 133633

(Core :: Graphics: Image Blocking, defect)

Description

[Robert G. Ristroph]

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.

Comment 1

[John Morrison]

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].

Comment 2

[R.K.Aa.]

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

Comment 3

[R.K.Aa.]

Attachment: backtrace

Comment 4

[John Morrison]

-> imagelib

Comment 5

[R.K.Aa.]

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.

Comment 6

[Andrew Schultz]

looks a lot like bug 126092

Comment 7

[Robert G. Ristroph]

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.

Comment 8

[R.K.Aa.]

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

Comment 9

[Dave]

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

TB3655961Q
TB3658284Z
TB3675217Y

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

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) 

Comment 12

[Robert G. Ristroph]

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.

Comment 13

[Jay Patel [:jay]]

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

Comment 14

[R.K.Aa.]

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

Comment 15

[Stuart Parmenter]

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

Comment 16

[Bert Driehuis]

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.

Comment 17

[Bert Driehuis]

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).

Comment 18

[Jay Patel [:jay]]

Marking dup of bug 133633, please reopen if you disagree.

*** This bug has been marked as a duplicate of 133633 ***