This is the page: <frameset rows="120,*"> <frameset cols="25,*"> <frame src="foo.html"> </frameset> </frameset> And this is foo.html: <table> <tr> <td> <img src="http://www.google.com/images/title_homepage4.gif" WIDTH="8" HEIGHT="40000"> </td> </tr> </table>

Is this a crash? Does the frameset matter? My guess is we just run out of memory trying to scale the image. Steve Fink, do you see the crash without the frameset thing?

Image scaling is broken on linux in some cases too. bug 74313.

clearing target milestone since 0.9 is past anyway and that field is for the developer working on the bug....

Oops, sorry. Forgot to mention what actually happens. Yes, it crashes. It does not crash on a coworker's browser of the same version, or his browser of a later version. It does crash on his mozilla at home (don't know the version), and it used to crash on his browser at work. It crashes a few other coworkers' mozillas too. Removing any of the frameset column or row widths makes it not crash. Removing either the width or height field of the img makes it not crash. The test case is pretty close to minimal. The .gif file used doesn't matter.

changing severity; adding keyword. Steve, could you try a build with talkback (you'll have to use a sea installer build) and post the talkback ID from the crash here?

This is a talkback build, so I've sent quite a few for the same problem already: TB31204926Q TB31199175W TB31192047M TB31191641Q TB30885160Z All of those should be the same problem. The 1st four were file: urls, the last was the original problem with an http: url.

Asa, could you pull those stack traces?

Despite the frameset and table requirements, I think Stuart might be able to make the most sense out of this one - here's a stack from the last mentioned talkback id: libX11.so.6 + 0x20682 (0x4073b682) NNScaleImage() DoScale() DrawScaledImageNN() nsImageGTK::DrawScaled() nsImageGTK::Draw() nsRenderingContextImpl::DrawScaledImage() 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::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() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsContainerFrame::Paint() PresShell::Paint() nsView::Paint() nsViewManager::RenderDisplayListElement() nsViewManager::RenderViews() nsViewManager::Refresh() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWindow::DoPaint() nsWindow::Update() nsWindow::UpdateIdle() libglib-1.2.so.0 + 0x11139 (0x406fd139) libglib-1.2.so.0 + 0x10186 (0x406fc186) libglib-1.2.so.0 + 0x10751 (0x406fc751) libglib-1.2.so.0 + 0x108f1 (0x406fc8f1) libgtk-1.2.so.0 + 0x8c5b9 (0x406245b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x401e99cb)

Just checked, all TB incidents have an identical stack.

I don't see this with the patch from 83920 in my tree on solaris. (the code crashing is removed)

fixed by the checkin for bug 83920