This one was first seen way back in bug 74087. According to pavlov (comment #2) it was due to negative coordinates. But apparently no reproducible case or fix was found and the crashes disappeared. Now we are seeing this crash in the N700 data and the branch data in significant numbers. (Roughly 200 crashes combined.) cc'ing cbiesinger who has been able to reproduce this one several times. Christian, can you provide steps to crash? Stack Trace: nsImageWin::DrawComposited24 [d:\builds\seamonkey\mozilla\gfx\src\windows\nsImageWin.cpp line 647] nsImageWin::DrawComposited [d:\builds\seamonkey\mozilla\gfx\src\windows\nsImageWin.cpp line 677] nsImageWin::Draw [d:\builds\seamonkey\mozilla\gfx\src\windows\nsImageWin.cpp line 534] nsRenderingContextImpl::DrawImage [d:\builds\seamonkey\mozilla\gfx\src\nsRenderingContextImpl.cpp line 923] nsImageBoxFrame::PaintImage [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp line 533] nsImageBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp line 481] nsBoxFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1699] nsBoxFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1836] nsBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1652] nsBoxFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1699] nsBoxFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1836] nsBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1652] nsBoxFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1699] nsBoxFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1836] nsBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1652] nsBoxFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1699] nsBoxFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1836] nsBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1652] nsBoxFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1699] nsBoxFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1836] nsBoxFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1652] nsContainerFrame::PaintChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 282] nsContainerFrame::PaintChildren [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 200] nsContainerFrame::Paint [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 181] PresShell::Paint [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5876] nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 280] nsViewManager::RenderDisplayListElement [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1187] nsViewManager::RenderViews [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1136] nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 727] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1727] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 83] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 1033] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 1055] nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 4736] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 3596] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 1295] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407)

ok, I now managed to reproduce this again. you _really_ need to drain your GDI resources. (I did that by opening new windows, loading sites like netscape.com, cnn.com, aol.com, pcwelt.de in them) (I got down to 1% free or so). then you can switch to another app and back to netscape, and get the crash

somewhat related to bug 148879 2 possibilities: 1) mozilla somehow leaks GDI objects (can be seen with NT task manager) 2) mozilla crash when GDI resources are low Is it specific to windows 98/Me ?

Thanks Bernard, I was looking for that bug to see if the same steps reproduced the crash. And yes, it is specific to Win98. In fact, we don't have any incidents on ME at all (yet).

Can we add few memory/handle checks to avoid the crash ? 654 /** --------------------------------------------------- 655 * Blend the image into a 24 bit buffer.. using an 8 bit alpha mask 656 * @update 1/04/02 dwc 657 */ 658 void nsImageWin::DrawComposited(HDC TheHDC, int aDX, int aDY, int aDWidth, int aDHeight, 659 int aSX, int aSY, int aSWidth, int aSHeight) 660 { 661 HDC memDC = CreateCompatibleDC(TheHDC); 662 unsigned char *screenBits; 663 ALPHA24BITMAPINFO bmi(aSWidth, aSHeight); 664 HBITMAP tmpBitmap = ::CreateDIBSection(memDC, (LPBITMAPINFO)&bmi, DIB_RGB_COLORS, 665 (LPVOID *)&screenBits, NULL, 0); 666 HBITMAP oldBitmap = (HBITMAP)::SelectObject(memDC, tmpBitmap); 667 668 /* Copy from the HDC */ 669 ::StretchBlt(memDC, 0, 0, aSWidth, aSHeight, 670 TheHDC, aDX, aDY, aDWidth, aDHeight, SRCCOPY); 671 672 /* Do composite */ 673 DrawComposited24(screenBits, aSX, aSY, aSWidth, aSHeight); 674 675 /* Copy back to the HDC */ 676 ::StretchBlt(TheHDC, aDX, aDY, aDWidth, aDHeight, 677 memDC, 0, 0, aSWidth, aSHeight, SRCCOPY); 678 679 ::SelectObject(memDC, oldBitmap); 680 ::DeleteObject(tmpBitmap); 681 ::DeleteDC(memDC); 682 }

grrr. I was unable to reproduce this crash with mozilla nightly (from aug. 30). so the problem does not seem to be the function namachi mentions. oh wait a second in trunk this function looks slightly different - an error check was added. this was part of the patch for bug 101018 (the last part of the patch there). well... I do have a patch now to add more error checking to this function, which is probably no bad thing in any case. I'll attach it in a second. (for trunk. branch seems to require a slightly different patch). taking bug. also cc'ing paper who wrote the patch which added the nullcheck, for review and because he might be interested anyway

Comment on attachment 98002 [details] [diff] [review] better patch r=paper

Comment on attachment 98002 [details] [diff] [review] better patch sr=tor

Comment on attachment 98116 [details] [diff] [review] 1.0 branch patch tranferring r=paper sr=tor from trunk patch, as there were no significant changes

ok, I'm not 100% sure that this will fix the crash, and I don't think I'll be able to verify this as I can't reproduce the crash with 1.0 branch builds but, I think this should do it. and one way or another, added error checking is a good thing.

Comment on attachment 98002 [details] [diff] [review] better patch a=rjesup@wgate.com

Comment on attachment 98116 [details] [diff] [review] 1.0 branch patch a=rjesup@wgate.com for 1.0 branch. CHange mozilla1.0.2+ to fixed1.0.2 when checked in

ok I checked this into 1.0 branch and trunk now; therefore marking fixed. if this patch did not fix the problem (ie. if you still see these crashes), please reopen and assign to default owner.

This one isn't showing up in Trunk or branch builds since checkin. Marking VERIFIED. Good work, Christian!

Thanks :) but shouldn't this get the keyword verified1.0.2 then as well?

You're right. Good catch. :)