Seen while testing Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre. 1. Visit sandisk site. 2. Crash Breakpad is http://crash-stats.mozilla.com/report/index/b954dcf3-ab86-11dd-9e5d-001321b13766

This does not crash using the latest nightly on Mac.

it looks like the machine in the lab running Win Vista Business does not crash on this site. The machine I crashed on is running Win Vista Ultimate. There are no exztensions installed in this profile.

I ran into this one a few times reloading this page: http://forums.mozillazine.org/viewforum.php?f=23 It's not reliably reproducible though. e.g. bp-18fc3194-abb3-11dd-9e47-001cc45a2c28 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre ID:20081105032350

It also happened just switching to the tab with that page.

0 xul.dll fbFetchPixel_x8r8g8b8 gfx/cairo/libpixman/src/pixman-access.c:819 1 xul.dll fbFetchFromNoRegion gfx/cairo/libpixman/src/pixman-transformed.c:53 2 xul.dll fbFetchTransformed_Bilinear_Pad gfx/cairo/libpixman/src/pixman-transformed.c:341 3 xul.dll fbFetchTransformed gfx/cairo/libpixman/src/pixman-transformed.c:624 4 xul.dll pixman_composite_rect_general_no_accessors gfx/cairo/libpixman/src/pixman-compose.c:490 5 xul.dll pixman_composite_rect_general gfx/cairo/libpixman/src/pixman-compose.c:589 6 xul.dll pixman_image_composite_rect gfx/cairo/libpixman/src/pixman-pict.c:1338 7 xul.dll pixman_walk_composite_region gfx/cairo/libpixman/src/pixman-pict.c:1290 8 xul.dll _moz_pixman_image_composite gfx/cairo/libpixman/src/pixman-pict.c:1966 I want to be sure that the stack isn't lost after 1-2 years :-)

Unfortunately the cairo/pixman update (Bug 462938) didn't fix this. It still crashes with today's build. bp-7511f8f3-ac1e-11dd-9b0b-001cc45a2c28 The second frame from the top in the previous stack is no longer in the new stack.

could someone get this in a debugger? http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg catch me or someone else on irc. i want to look at local variables. i should be around later in the weekend.

adding ctalbert to the bug with the hopes he can catch this in a debug build...

I just noticed that in about:config I have both JITs set to true (content and chrome). But when I tried to repro on other machines with both JITs on I did not get the crash.

marcia: you don't need a debug build, any windows build will work. just find me on irc and i'll talk someone through it.

Jeff, now that you've got a happy windows box, can you take a look at this when you get a chance?

yeah, i don't want a stack. i either need to talk to you, or you need to make a dump .dump /maipwd /u /b /c "bug 463301" c:\463301 the question what do the local variables look like. based on the fact we're fighting an optimizer, it may involve checking their values in calling frames and calculating them. i suppose the following commands might work: .frame /r 0 dv /itV .frame /r 1 dv /itV

I couldn't catch you on IRC, i have the crash in windbg. My Seamonkey crashes very frequently with this stack. in the last 2 days when the new mail notification comes up: bp-84c4e173-aced-11dd-907f-001cc45a2ce4 0:000> .frame /r 0 00 002c800c 6e0e1d15 thebes!fbFetchPixel_a8r8g8b8+0x13 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\gfx\cairo\libpixman\src\pixman-access.c @ 812] eax=053bed40 ebx=ffffffff ecx=ffffffff edx=02140000 esi=000000d6 edi=0000002a eip=6e0de353 esp=002c8010 ebp=ffffffff iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 thebes!fbFetchPixel_a8r8g8b8+0x13: 6e0de353 8b048a mov eax,dword ptr [edx+ecx*4] ds:0023:0213fffc=???????? 0:000> dv /itV 0:000> .frame /r 1 01 002c8064 6e0e28cc thebes!fbFetchTransformed_Bilinear_Pad+0x245 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\gfx\cairo\libpixman\src\pixman-transformed.c @ 330] eax=053bed40 ebx=ffffffff ecx=ffffffff edx=02140000 esi=000000d6 edi=0000002a eip=6e0e1d15 esp=002c8014 ebp=ffffffff iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 thebes!fbFetchTransformed_Bilinear_Pad+0x245: 6e0e1d15 8b4c2420 mov ecx,dword ptr [esp+20h] ss:0023:002c8034=ffffffff 0:000> dv /itV I have written a dumb file, i could put it on my local http server but the download might be slow because my DSL upload is limited.

I can reproduce the crash 100% when I load http://www.mtv.com/videos/ti/294775/live-your-life.jhtml#artist=1225081 and http://www.facebook.com in separate tabs; by the time the browser loads Facebook, I crash. This is with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081107 Minefield/3.1b2pre; hopefully someone with a debug build can crash using those steps.

Same here reading gmail email messages. http://crash-stats.mozilla.com/report/index/2cb61f38-adfa-11dd-b0df-001321b13766 Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre

according to http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.1b2pre regression range: latest without this crash: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre Built from http://hg.mozilla.org/mozilla-central/rev/fbae114d6133 first build id having this crash: 20081105032350 Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre Built from http://hg.mozilla.org/mozilla-central/rev/dcec193ba5d7 regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fbae114d6133&tochange=dcec193ba5d7 but it seems to be triggered most with build id 20081107043838 Here it happens with Windows XP.

I crash every time at http://sandisk.com/ after I've zoomed in on that page, using current trunk build.

After reading the comments on crash reports, I find mostly reproducible by zooming and then scrolling after loading the sites reported there. such as: zomm+scroll at http://arstechnica.com/ http://www.iltalehti.fi/ and so on. btw, I'm not able to reproduce the crash at http://sandisk.com/ Another way seems to log into gmail, zoom the page and stay with the mouse over the names of the left chat. see reports tab in: http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&version=Firefox%3A3.1b2pre&signature=fbFetchPixel_x8r8g8b8 and http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&version=Firefox%3A3.1b2pre&signature=fbFetchPixel_a8r8g8b8

The Gmail hint was perfect. I'm able to trigger that crash now with my debug build. I'll attach a full stack soon.

For me the crash starts between the following builds: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081106 Minefield/3.1b2pre ID:20081106033429 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081107 Minefield/3.1b2pre ID:20081107043838 Check-ins in this timeframe: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-11-06+03%3A00%3A00&enddate=2008-11-07+05%3A00%3A00 Bug 449356 could be a really good candidate here. CC'ing Karl who has written the patch on the mentioned bug.

It won't be related to bug 449356 as that was Linux-only platform code. It's possible that the changes in the regression range are just incidental, resulting in invocation a code path which has had a bug for some time.

Is this win32 only, or can anyone reproduce on linux? If so, we should be able to get valgrind on it.

Sadly its Win only. There are no crashes listed for Linux or OS X. Which information is needed to fix this bug?

[object XULElement] Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no]

tharindu, that's bug 459790

Looks like we are trying to draw a zero sized image surface and clip it to -1. Not sure why yet.

While looking at the stack it should be a background-image, right? I tried to identify its name but wasn't successful in doing this. Any hints where I can get this information?

This should probably block beta 2 given its frequency on Vista...

This should make the problem go away. It isn't really correct, but I'm not sure if it will affect Firefox.

Comment on attachment 347611 [details] [diff] [review] hack to work around the problem >+ /* don't draw anything because we don't have anything to draw to */ >+ if (pDst->bits.width == 0 && pDst->bits.width == 0) { >+ return; >+ } I'm still sure you meant width and height here.

I did, but the patch should still be just as functional.

I don't know if it is somehow related but with a debug build I get several of these assertions you can find in the stack. The number depends on the amount of table rows for the chat members displayed on the Gmail website.

I narrowed down the list of possible changesets in the given time frame (comment 22). As what it looks like changeset http://hg.mozilla.org/mozilla-central/rev/4f773b27f033 is a very good candidate for this topcrash regression. Means Roc's fix in bug 456330 could be the reason. > 7 - gfxMatrix().Translate(gfxPoint(aPadding.left, aPadding.top))); > 8 + gfxMatrix().Translate(-gfxPoint(aPadding.left, aPadding.top))); The change in nsThebesImage::Draw is consistent with frame 21 of my stack (attachment 347191 [details])

This is probably close to what the actual fix will be.

(In reply to comment #37) > I narrowed down the list of possible changesets in the given time frame > (comment 22). As what it looks like changeset > http://hg.mozilla.org/mozilla-central/rev/4f773b27f033 is a very good candidate > for this topcrash regression. Means Roc's fix in bug 456330 could be the > reason. > > > 7 - gfxMatrix().Translate(gfxPoint(aPadding.left, aPadding.top))); > > 8 + gfxMatrix().Translate(-gfxPoint(aPadding.left, aPadding.top))); > > The change in nsThebesImage::Draw is consistent with frame 21 of my stack > (attachment 347191 [details]) This change may or may not be broken. Either way, it exposes a latent bug that the patch I just posted should fix.

Sorry, there were two check-ins right behind each other. I selected the wrong with a 50% chance. The patch on bug 463204 caused this crash. 4f773b27f033 works fine while 8adf110592e9 crash. Updating dependency list.

Jeff, think we can get something in for this tomorrow to make the beta? Even if a bandaid.

Accroding to http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&version=Firefox%3A3.1b2pre&signature=fbFetchPixel_a8r8g8b8 Even if the crash amount increased in the 20081107 build, this crash has started two days before, regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fbae114d6133&tochange=dcec193ba5d7

could it be bug 458487 the real cause of the regression?

Sure could be.

nsThebesImage::Draw is being called with aFill set to 379,124,327,1. The image is 247x29. aSubimage is 28,0,219,29. aUserSpaceToImageSpace is xx=2/3,yy=2/3,x0=-223 2/3,y0=-53 2/3. That means sourceRect=29,29,218,2/3. It lies entirely outside the aSubimage... So we compute 'needed' to be an empty rectangle and it's all downhill from there.

(This is for the sandisk.com crash, or at least the one I'm reproducing.)

nsLayoutUtils::DrawImage is trying to fill 378.7,81,327.05,43.5. That gets snapped to 379,81,327,44, OK. The input dirty area is 378.7,124,327.05,0.5. The anchor point is 702.75,102.75. The anchor point is snapped to 706,103. The snapped image space anchor point is 247,15. Perhaps the biggest issue here is that nsLayoutUtils::DrawImage should not be clipping the fill rect by the dirty area. That's not safe whenever the user-space-to-image-space transform is not a straight translation by pixels, because filtering is happening, and that means changing the fill rect changes the pixel values rendered for the image at the fill rect boundary.

This fixes the crash on sandisk.com and will probably fix most situations where we could end up with an empty 'needed' rect. It's also the right thing to do. I should try to write a crashtest. But the big unaddressed issue is that we need some careful analysis of nsLayoutUtils::DrawImage and possibly further changes to ensure that it always passes parameters to nsThebesImage::Draw that lead to the source rect intersecting the subimage rect.

The previous version of this patch got the test backwards. This version fixes that. While testing the patch I ran into XCreatePixmap trying to make zero sized images so this patch also adds a similar to test to the Xlib surface.

Comment on attachment 347753 [details] [diff] [review] fix Reasking for r/sr after an accidentally reset of these flags.

Improved comment to explain why this check is what it is. Also, moved the finalFillRect.IsEmpty() check out so it always happens.

Using today's build on Vista (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre) I crash every time I login to Yahoo mail. STR: 1. Visit https://login.yahoo.com/config/mail?.intl=us 2. Enter my user name and password 3. Hit the "Sign In' button Using these steps I crash 100% of the time. Just wanted to document this since I had seen it previously - only sandisk.com was crashing for me all the time in this stack.

In Comment 53 I meant I had *not* seen this previously.

Comment on attachment 347768 [details] [diff] [review] v2 Don't create 0 size surfaces. works for me; bandaid for sure, but better than crashing.

(In reply to comment #55) > (From update of attachment 347768 [details] [diff] [review]) > works for me; bandaid for sure, but better than crashing. Can you check it in when possible?

This version against the mozilla tree removes the X stuff because that only applies to cairo upstream right now. It also passes the reftests on windows so should be ready to go.

Landed jeff's patch (v3) - http://hg.mozilla.org/mozilla-central/rev/488dc9ecb6a3

I'd like to confirm that my dupe bug 464430 - which had different symptoms other than crash, at least for me - is also fixed by this patch. Awesome. Confirmed using a an hourly build built from revision 741151e3570e

Comment on attachment 347848 [details] [diff] [review] nsLayoutUtils fix, v2 r+sr=dbaron It might also make sense to turn this into a !finalFillRect.IsEmpty() test and just indent the next 4 lines rather than having an early return, but either way is fine. (In theory you ought to be using some sort of stack pusher object to reset the matrix so you don't have to do it for every early return.) >+ if (finalFillRect.IsEmpty()) { >+ ctx->SetMatrix(currentMatrix); >+ return NS_OK; >+ } > > nsIntRect innerRect; > imgFrame->GetRect(innerRect); > nsIntMargin padding(innerRect.x, innerRect.y, > imageSize.width - innerRect.XMost(), imageSize.height - innerRect.YMost()); > img->Draw(ctx, transform, finalFillRect, padding, intSubimage); > ctx->SetMatrix(currentMatrix); > return NS_OK;

My dupe 464228 was fixed by this patch, yeey. Thanks everyone.

Is this FIXED?

The cairo workaround that has been landed works for me. There is another patch from roc that, if I understand correctly, tries to solve the root of the cause. This has not been landed yet.

We can mark this FIXED, although we should still check in my patch after beta2.

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre. I no longer see the crash on sandisk.com or in yahoo mail

(In reply to comment #66) > We can mark this FIXED, although we should still check in my patch after beta2. Roc, the tree is red now but can you do that in the next time?

I filed bug 467283 to handle the landing of my patch here.

No crash for beta 2 in the last 3 weeks. Setting verified keyword.