Closed
Bug 463301
Opened 16 years ago
Closed 16 years ago
Crash in [@ fbFetchPixel_x8r8g8b8] [@ fbFetchPixel_a8r8g8b8] when loading sandisk.com using Vista Ultimate
Categories
(Core :: Graphics, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b2
People
(Reporter: marcia, Assigned: roc)
References
()
Details
(4 keywords)
Crash Data
Attachments
(6 files, 4 obsolete files)
3.91 KB,
text/plain
|
Details | |
9.26 KB,
text/plain
|
Details | |
11.98 KB,
text/plain
|
Details | |
8.21 KB,
text/plain
|
Details | |
5.47 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
782 bytes,
patch
|
Details | Diff | Splinter Review |
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
Flags: blocking1.9.1?
Reporter | ||
Comment 1•16 years ago
|
||
This does not crash using the latest nightly on Mac.
Reporter | ||
Comment 2•16 years ago
|
||
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.
Reporter | ||
Updated•16 years ago
|
Summary: Crash in [fbFetchPixel_x8r8g8b8] when loading sandisk.com → Crash in [fbFetchPixel_x8r8g8b8] when loading sandisk.com using Vista Ultimate
Comment 3•16 years ago
|
||
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
Comment 4•16 years ago
|
||
It also happened just switching to the tab with that page.
Comment 5•16 years ago
|
||
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 :-)
Summary: Crash in [fbFetchPixel_x8r8g8b8] when loading sandisk.com using Vista Ultimate → Crash in [@ fbFetchPixel_x8r8g8b8] when loading sandisk.com using Vista Ultimate
Comment 6•16 years ago
|
||
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.
Reporter | ||
Comment 8•16 years ago
|
||
adding ctalbert to the bug with the hopes he can catch this in a debug build...
Reporter | ||
Comment 9•16 years ago
|
||
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.
Comment 10•16 years ago
|
||
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?
Assignee: nobody → jmuizelaar
Comment 12•16 years ago
|
||
Comment 13•16 years ago
|
||
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
Comment 14•16 years ago
|
||
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.
Comment 16•16 years ago
|
||
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
Comment 17•16 years ago
|
||
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.
Keywords: regression
Comment 18•16 years ago
|
||
I crash every time at http://sandisk.com/ after I've zoomed in on that page, using current trunk build.
Comment 19•16 years ago
|
||
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
Comment 20•16 years ago
|
||
The Gmail hint was perfect. I'm able to trigger that crash now with my debug build. I'll attach a full stack soon.
Comment 21•16 years ago
|
||
Comment 22•16 years ago
|
||
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.
Comment 23•16 years ago
|
||
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.
Comment 25•16 years ago
|
||
Sadly its Win only. There are no crashes listed for Linux or OS X. Which information is needed to fix this bug?
Comment 27•16 years ago
|
||
[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]
Comment 28•16 years ago
|
||
tharindu, that's bug 459790
Comment 29•16 years ago
|
||
Looks like we are trying to draw a zero sized image surface and clip it to -1. Not sure why yet.
Comment 30•16 years ago
|
||
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?
Comment 32•16 years ago
|
||
This should probably block beta 2 given its frequency on Vista...
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.1b2
Comment 33•16 years ago
|
||
This should make the problem go away. It isn't really correct, but I'm not sure if it will affect Firefox.
Comment 34•16 years ago
|
||
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.
Comment 35•16 years ago
|
||
I did, but the patch should still be just as functional.
Comment 36•16 years ago
|
||
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.
Comment 37•16 years ago
|
||
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])
Blocks: 456330
Comment 38•16 years ago
|
||
This is probably close to what the actual fix will be.
Attachment #347611 -
Attachment is obsolete: true
Comment 39•16 years ago
|
||
(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.
Comment 40•16 years ago
|
||
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.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Comment 42•16 years ago
|
||
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
Comment 43•16 years ago
|
||
could it be bug 458487 the real cause of the regression?
Assignee | ||
Comment 44•16 years ago
|
||
Sure could be.
Updated•16 years ago
|
Summary: Crash in [@ fbFetchPixel_x8r8g8b8] when loading sandisk.com using Vista Ultimate → Crash in [@ fbFetchPixel_x8r8g8b8] [@ fbFetchPixel_a8r8g8b8] when loading sandisk.com using Vista Ultimate
Assignee | ||
Comment 46•16 years ago
|
||
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.
Assignee | ||
Comment 47•16 years ago
|
||
(This is for the sandisk.com crash, or at least the one I'm reproducing.)
Assignee | ||
Comment 48•16 years ago
|
||
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.
Assignee | ||
Comment 49•16 years ago
|
||
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.
Assignee: jmuizelaar → roc
Attachment #347753 -
Flags: superreview?(dbaron)
Attachment #347753 -
Flags: review?(dbaron)
Comment 50•16 years ago
|
||
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.
Attachment #347753 -
Attachment is obsolete: true
Attachment #347753 -
Flags: superreview?(dbaron)
Attachment #347753 -
Flags: review?(dbaron)
Updated•16 years ago
|
Attachment #347753 -
Attachment is obsolete: false
Updated•16 years ago
|
Attachment #347659 -
Attachment is obsolete: true
Updated•16 years ago
|
Attachment #347753 -
Flags: superreview?(dbaron)
Attachment #347753 -
Flags: review?(dbaron)
Comment 51•16 years ago
|
||
Comment on attachment 347753 [details] [diff] [review]
fix
Reasking for r/sr after an accidentally reset of these flags.
Updated•16 years ago
|
Attachment #347768 -
Flags: review?(vladimir)
Assignee | ||
Comment 52•16 years ago
|
||
Improved comment to explain why this check is what it is. Also, moved the finalFillRect.IsEmpty() check out so it always happens.
Attachment #347753 -
Attachment is obsolete: true
Attachment #347848 -
Flags: superreview?(dbaron)
Attachment #347848 -
Flags: review?(dbaron)
Attachment #347753 -
Flags: superreview?(dbaron)
Attachment #347753 -
Flags: review?(dbaron)
Reporter | ||
Comment 53•16 years ago
|
||
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.
Reporter | ||
Comment 54•16 years ago
|
||
In Comment 53 I meant I had *not* seen this previously.
Attachment #347768 -
Flags: review?(vladimir) → review+
Comment on attachment 347768 [details] [diff] [review]
v2 Don't create 0 size surfaces.
works for me; bandaid for sure, but better than crashing.
Comment 56•16 years ago
|
||
(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?
Comment 58•16 years ago
|
||
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.
Attachment #347768 -
Attachment is obsolete: true
Updated•16 years ago
|
Keywords: checkin-needed
Comment 59•16 years ago
|
||
Landed jeff's patch (v3) - http://hg.mozilla.org/mozilla-central/rev/488dc9ecb6a3
Updated•16 years ago
|
Attachment #347974 -
Attachment description: v3 Don't create 0 size pixman images → v3 Don't create 0 size pixman images (checked-in)
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Whiteboard: [needs review]
Comment 60•16 years ago
|
||
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;
Attachment #347848 -
Flags: superreview?(dbaron)
Attachment #347848 -
Flags: superreview+
Attachment #347848 -
Flags: review?(dbaron)
Attachment #347848 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review] → [needs landing]
Comment 63•16 years ago
|
||
My dupe 464228 was fixed by this patch, yeey. Thanks everyone.
Comment 64•16 years ago
|
||
Is this FIXED?
Comment 65•16 years ago
|
||
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.
Assignee | ||
Comment 66•16 years ago
|
||
We can mark this FIXED, although we should still check in my patch after beta2.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 67•16 years ago
|
||
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
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Flags: in-testsuite?
Comment 68•16 years ago
|
||
(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?
Assignee | ||
Comment 69•16 years ago
|
||
I filed bug 467283 to handle the landing of my patch here.
Whiteboard: [needs landing]
Updated•16 years ago
|
Keywords: fixed1.9.1
Comment 70•16 years ago
|
||
No crash for beta 2 in the last 3 weeks. Setting verified keyword.
Keywords: fixed1.9.1 → verified1.9.1
Updated•14 years ago
|
Crash Signature: [@ fbFetchPixel_x8r8g8b8]
[@ fbFetchPixel_a8r8g8b8]
You need to log in
before you can comment on or make changes to this bug.
Description
•