Closed Bug 359054 Opened 18 years ago Closed 18 years ago

crash [@ _moz_cairo_pixman_composite_src_8888x8888mmx ] [@ fbCompositeSrc_8888x8888]

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Peter6, Assigned: vlad)

References

(
URL
)

Details

(Keywords: crash, regression, Whiteboard: [blocking1.9a1+])

Crash Data

Attachments

(3 files)

backtrace from debug build
7.79 KB, text/plain
Details
disable MMX until we can track this down
480 bytes, patch
pavlov
: review+
Details | Diff | Splinter Review
potential fix
1.38 KB, patch
pavlov
: review+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1 ID:2006110103 [cairo]

repro:
1.open url
2.select a catagory
3.wait for the page to load.

result:
it crashes right a way
it crahes after scrolling

reported to crash FF1.5 and 2.0 aswell
no crash in EI6/7 or Opera9

TB25352150M

Incident ID: 25352150
Stack Signature	firefox.exe + 0x543863 (0x00943863) 1d6de24d
Product ID	FirefoxTrunk
Build ID	2006110104
Trigger Time	2006-11-01 07:14:45.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00543863)
URL visited	
User Comments	browsing wallpapers.org, select catagory and scroll page - crash
Since Last Crash	3720 sec
Total Uptime	3720 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
firefox.exe + 0x543863 (0x00943863)
firefox.exe + 0x5454ed (0x009454ed)
firefox.exe + 0x53d8e0 (0x0093d8e0)
Incident ID: 25356383
Stack Signature	firefox.exe + 0x543863 (0x00943863) 1d6de24d
Product ID	FirefoxTrunk
Build ID	2006103112
Trigger Time	2006-11-01 08:49:23.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (00543863)
URL visited	http://wallpapers.org/
User Comments	crash on wallpapers.org after selecting a catagory
Since Last Crash	7641 sec
Total Uptime	7641 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
firefox.exe + 0x543863 (0x00943863)
firefox.exe + 0x5454ed (0x009454ed)
firefox.exe + 0x53d8e0 (0x0093d8e0)

equally useless but consistent
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1 (bangbang023)

WFM, Windows 2000 only ?
Ok, with a 2006-10-30 trunk build, I get useful talkback data:
Talkback ID: TB25360619Y
_moz_cairo_pixman_composite_src_8888x8888mmx  [mozilla\gfx\cairo\libpixman\src\fbmmx.c, line 1430]
_moz_cairo_pixman_composite  [mozilla\gfx\cairo\libpixman\src\fbpict.c, line 1892]
_cairo_image_surface_composite  [mozilla\gfx\cairo\cairo\src\cairo-image-surface.c, line 819]

So this seems like a Gfx->Thebes crash bug to me, which normally only would happen on trunk.
Can the person(s) who crash on 1.5/2.0 branch post talkback ID's of those crashes?
Severity: normal → critical
Component: General → GFX: Thebes
Flags: blocking1.9?
Keywords: crash
Product: Firefox → Core
Summary: crash [@ firefox.exe] → crash [@ _moz_cairo_pixman_composite_src_8888x8888mmx ]
Version: unspecified → Trunk
I had the 2.0 and 1.5 crashes, but TB did not launch in either instance. As I can't reproduce, we should assume this is Gfx->Thebes only.
I crashed the trunk on both Win2k and WinXP.  The talkbacks were like the first two comments.  But I could not get 1.5.0.7 to crash on either OS.

The earliest build in the talkback reports with the cairo signature is 2006102704.
Looking at the 24 hours previous to that:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-26+04%3A00%3A00&maxdate=2006-10-27+04%3A00%3A00&cvsroot=%2Fcvsroot

This looks a lot like it's due to bug 356354.  This is crashing in fbmmx.c and that bug's patch made changes to that file.  
No crash for me in Linux (Minefield 2006110104)
(In reply to comment #5)
> The earliest build in the talkback reports with the cairo signature is
> 2006102704.
> Looking at the 24 hours previous to that:
> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-26+04%3A00%3A00&maxdate=2006-10-27+04%3A00%3A00&cvsroot=%2Fcvsroot
> 
> This looks a lot like it's due to bug 356354.  This is crashing in fbmmx.c and
> that bug's patch made changes to that file.  
> 
the firefox-3.0a1.en-US.win32_20061026_1611pdt build, from just before bug 356354 landed, crashes like the current ones.

For as far as I can see this regressed between:

works in firefox-3.0a1.en-US.win32_20061026_1003pdt build
fails in firefox-3.0a1.en-US.win32_20061026_1234pdt build

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20061026+091500&maxdate=20061026+123400&cvsroot=%2Fcvsroot

which would suggest bug 357761




Looks can be deceiving. :(

I've yet to crash in 2006102604.  If that holds up. :) Then there are two other thebes checkins in the reduced regression window:
bug 357761 and the patch for both bug 352488 and bug 324803.
QA Contact: general → thebes
WFM (Vista Build 5744)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1 ID:2006110104 [cairo]
(In reply to comment #8)
> For as far as I can see this regressed between:
> 
> works in firefox-3.0a1.en-US.win32_20061026_1003pdt build
> fails in firefox-3.0a1.en-US.win32_20061026_1234pdt build
> 
> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20061026+091500&maxdate=20061026+123400&cvsroot=%2Fcvsroot
> 
> which would suggest bug 357761
> 
Doing what little debugging that I can and looking at bug 357761 I see that nsThebesImage::ThebesDrawTile was added in that bug and is in the call stack when I crash.
Blocks: 357761
Can you guys that are crashing post CPU info?  I can't reproduce this crash (Pentium M 2.13ghz) in either debug or the release nightly builds.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061102 Minefield/3.0a1 ID:2006110208 [cairo]

om an AMD Athlon 850Mhz
Both of my machines are Pentium 4s (3.06 gHz).  Would posting a stack help?  
Celeron D 2.80GHz

TB will not launch for me with this crash.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1 ID:2006110604 [cairo]
Keywords: regression
WFM with Prescott 2.4A.
Ok, I can reproduce in a debug build now, this is the backtrace I get.
If you need more/other info, just ask.
So the intermediate bandaid would be to just disable MMX; it's not really crucial for browser performance, it more helps SVG, and we can figure out what's going on here after the alpha.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [blocking1.9a1+]
Assignee: nobody → vladimir
Let's disable MMX as a workaround for 1.9a1 and fix after.  (I'll leave this bug open even after checking in.)
Attachment #245270 - Flags: review?(pavlov)
Attachment #245270 - Flags: review?(pavlov) → review+
MMX disabled on the trunk, clearing 1.9a1+.  We should revisit this after the alpha though, because we do want the MMX optimizations to be on.
Whiteboard: [blocking1.9a1+]
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061110 Minefield/3.0a1 ID:2006111015 [cairo] - with MMX disabled

hmm, I'm still crashing on this Vlad
(In reply to comment #21)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061110
> Minefield/3.0a1 ID:2006111015 [cairo] - with MMX disabled
> 
> hmm, I'm still crashing on this Vlad

Uh.  You're crashing on that mmx function with MMX disabled?  Or crashing on the page?

It crashes but at a new place:TB25821706W
That crash is from this build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061110 Minefield/3.0a1 ID:2006111016 [cairo]
same stack here

Incident ID: 25830018
Stack Signature	fbCompositeSrc_8888x8888 14dcaf63
Product ID	FirefoxTrunk
Build ID	2006111014
Trigger Time	2006-11-10 23:33:58.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (0053a67a)
URL visited	
User Comments	Bug 359054 after MMX disabled
Since Last Crash	1209 sec
Total Uptime	1330 sec
Trigger Reason	Access violation
Source File, Line No.	e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\cairo\libpixman\src\fbpict.c, line 628
Stack Trace 	
fbCompositeSrc_8888x8888  [mozilla\gfx\cairo\libpixman\src\fbpict.c, line 628]
_moz_cairo_pixman_composite  [mozilla\gfx\cairo\libpixman\src\fbpict.c, line 1596]
_cairo_image_surface_composite  [mozilla\gfx\cairo\cairo\src\cairo-image-surface.c, line 830]
I crash with the same stacktrace at http://simon.incutio.com/ . That site has an animated gif at the right top of the page. That image also looks garbled sometimes in current trunk builds.
Do we need a different bug for the current crash ?
I don't think so, it seems to me also that the disabling MMX can be undone as it doesn't seem to fix the crash.
Summary: crash [@ _moz_cairo_pixman_composite_src_8888x8888mmx ] → crash [@ _moz_cairo_pixman_composite_src_8888x8888mmx ] [@ fbCompositeSrc_8888x8888]
Ugh, putting blocking back; I was hoping it would be just MMX, but apparently it's not.  I still can't reproduce this, but luckily a number of the people who can reproduce are here at the office this week, so I'll try to get a hold of people this week and figure out try to figure out what's going on.
Whiteboard: [blocking1.9a1+]
Attached patch potential fix — — Splinter Review 
So here's a potential fix; I wasn't able to crash my build with this applied, but it takes me a while to get to the crash (usually with wallpapers.org and doing a lot of scrolling).  Martijn, could you test your build with this patch and see if you can hit it?

For reference, the issue that I think is that the ownership/refcounting model between gfxASurface and cairo_surface still isn't 100% correct, and that the temporary surface that gets created (because xPadding/yPadding are not 0) is getting deallocated before cairo's done with it.  This is because gfxImageSurface allocates data and owns it, which it then frees in the destructor -- but cairo may have increased the refcnt on the cairo_surface_t.

The real fix for this is to clean up our refcounting story once and for all -- that is, the cairo_surface_t should hold the hard refcount, and we should only delete the gfx*Surface wrapper when that refcount goes to 0.  But this patch shold bandaid around this issue until the full one gets fixed.
(In reply to comment #29)
> So here's a potential fix; I wasn't able to crash my build with this applied,
> but it takes me a while to get to the crash (usually with wallpapers.org and
> doing a lot of scrolling).  Martijn, could you test your build with this patch
> and see if you can hit it?

Yeah, that patch seems to fix the crash. I browsed a few minutes through the galleries and I didn't crash with the patch (normally I would crash within a minute).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061126 Minefield/3.0a1 ID:2006112604 [cairo]

Just got this while normal browsing. 

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB26527883Y

Incident ID: 26527883
Stack Signature	 fbCompositeSrc_8888x8888 14dcaf63
Product ID	FirefoxTrunk
Build ID	2006112604
Trigger Time	2006-11-26 13:23:27.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00511c96)
URL visited	
User Comments	
Since Last Crash	3848 sec
Total Uptime	3848 sec
Trigger Reason	Access violation
Source File, Line No.	e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\cairo\libpixman\src\fbpict.c, line 627
Stack Trace 	
fbCompositeSrc_8888x8888  [mozilla\gfx\cairo\libpixman\src\fbpict.c, line 627]
_moz_cairo_pixman_composite  [mozilla\gfx\cairo\libpixman\src\fbpict.c, line 1892]
_cairo_image_surface_composite  [mozilla\gfx\cairo\cairo\src\cairo-image-surface.c, line 819]
*** Bug 361937 has been marked as a duplicate of this bug. ***
load this page http://www.arena-magazine.dk/page/638
and start scrolling I crash all the time
Comment on attachment 246347 [details] [diff] [review]
potential fix

Ok, let's go with this fix for now; I need to redo the refcounting stuff for surfaces, but that'll take a bit.
Attachment #246347 - Flags: review?(pavlov)
Attachment #246347 - Flags: review?(pavlov) → review+
Checked in, and mmx reenabled.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061127 Minefield/3.0a1 ID:2006112714 [cairo]

VERIFIED, No crashes on pages that crashed before
Given that MMX is apparently not to blame for this bug, why are we not using it in 1.8.1.x?  The file with the MMX code, fbmmx.c, is not included in the 1.8.1.1 make file.

(In reply to comment #37)
> Given that MMX is apparently not to blame for this bug, why are we not using it
> in 1.8.1.x?  The file with the MMX code, fbmmx.c, is not included in the
> 1.8.1.1 make file.
> 

Cairo/Thebes is only in 1.9.
Doesn't 1.8 use Cairo for SVG?
(In reply to comment #39)
> Doesn't 1.8 use Cairo for SVG?

Yes,  I'm running the mozlibpixman code right now in SeaMonkey v1.1.
Crash Signature: [@ _moz_cairo_pixman_composite_src_8888x8888mmx ] [@ fbCompositeSrc_8888x8888]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: