358767 - cairo crash @_cairo_pixman_render_line_fixed_edge_init on macosx

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[georgi - hopefully not receiving bugspam]

cairo crash @_cairo_pixman_render_line_fixed_edge_init on macosx

ff 2.0 and 1.5.0.7 crash on macosx @_cairo_pixman_render_line_fixed_edge_init
linux seems unaffected.

don't have debug macosx branch at the moment.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x070888bc
0x008fb67c in _cairo_pixman_render_line_fixed_edge_init ()
(gdb) bt
#0  0x008fb67c in _cairo_pixman_render_line_fixed_edge_init ()
#1  0x008bbb7c in fbRasterizeTrapezoid ()
#2  0x008bbb7c in fbRasterizeTrapezoid ()
#3  0x007dfc68 in _cairo_pixman_add_trapezoids ()
#4  0x00581b7c in _cairo_image_surface_assume_ownership_of_data ()
#5  0x005a0448 in _cairo_surface_fill_path ()
#6  0x007ded94 in _cairo_rectangle_intersect ()
#7  0x007de6c4 in _cairo_operator_bounded ()
#8  0x007df060 in _cairo_surface_clip_and_composite_trapezoids ()
#9  0x007df0e0 in _cairo_surface_clip_and_composite_trapezoids ()
#10 0x007de988 in _cairo_gstate_stroke ()
#11 0x0059ccb0 in cairo_stroke_preserve ()
#12 0x0059cc6c in cairo_stroke ()
#13 0x0057e224 in nsSVGCairoPathGeometry::Render ()
#14 0x0088cc64 in nsSVGPathGeometryFrame::PaintSVG ()
#15 0x006db240 in nsSVGGFrame::PaintSVG ()
#16 0x007598e4 in nsSVGOuterSVGFrame::Paint ()
#17 0x004c22f8 in nsContainerFrame::PaintChild ()
#18 0x004c21a8 in nsContainerFrame::PaintChildren ()
#19 0x00595c18 in nsHTMLContainerFrame::Paint ()
#20 0x006f6290 in CanvasFrame::Paint ()
#21 0x00151040 in PresShell::Paint ()
#22 0x004eafa0 in nsView::Paint ()
#23 0x001faf50 in nsViewManager::RenderDisplayListElement ()
#24 0x001fa858 in nsViewManager::RenderViews ()
#25 0x001f96a8 in nsViewManager::Refresh ()
#26 0x001fc564 in nsViewManager::DispatchEvent ()
#27 0x004eab8c in ViewWrapper::GetInterface ()
#28 0x00616038 in nsWindow::DispatchEvent ()
#29 0x00616100 in nsWindow::DispatchWindowEvent ()
#30 0x00615c60 in nsWindow::UpdateWidget ()
#31 0x00615d30 in nsWindow::UpdateWidget ()
#32 0x00615d30 in nsWindow::UpdateWidget ()

(gdb) x/i $pc
0x8fb67c <_cairo_pixman_render_line_fixed_edge_init+1504>:      lbzx    r0,r27,r7

Comment 1

[georgi - hopefully not receiving bugspam]

Attachment: testcase

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Looks like a few possible things going on here.  I don't know SVG well enough to know how big of a surface it will try to allocate for the attached testcase, but it could easily be allocating a too-small area due to integer overflow.  For linux and/or windows (testcase doesn't crash on windows trunk for me), it may be erroring out correctly from those surfaces.

tor, what kind of surface type does SVG use on OSX?  Is it the cairo_quartz_surface or cairo_image_surface?

Comment 3

[tor]

Trunk OS-X will use an image surface, branch OS-X will use a quartz surface.

Comment 4

[georgi - hopefully not receiving bugspam]

trunk doesn't crash for me.

i suspect either int overflow or null dereference.

Comment 5

[georgi - hopefully not receiving bugspam]

oops, os is macosx

Comment 6

[georgi - hopefully not receiving bugspam]

i am somewhat confused about this.

don't crash on a clean profile anymore (and since yesterday have applied apple's updates).

still crash on the original profile.

does anyone else crash on the testcase?

this well may be invalid.

Comment 7

[georgi - hopefully not receiving bugspam]

the stack with the *old profile* and debug 2.0-latest:
clean profile doesn't crash so far.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x205c08bc
0x07a5a6ac in fbRasterizeEdges8 (buf=0x1f261000, width=620, stride=155,
l=0xbfffc964, r=0xbfffc98c, t=2147297962, b=2147481462) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/libpixman/src/fbedge.c:157
157                     ap[lxi] = clip255 (ap[lxi] + rxs - lxs);
(gdb) p ap
$1 = (CARD8 *) 0x205c08bc <Address 0x205c08bc out of bounds>
(gdb) p lxi
$2 = 0
(gdb) p rxs
$3 = 5
(gdb) p lxs
$4 = 5
(gdb) bt
#0  0x07a5a6ac in fbRasterizeEdges8 (buf=0x1f261000, width=620, stride=155,
l=0xbfffc964, r=0xbfffc98c, t=2147297962, b=2147481462) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/libpixman/src/fbedge.c:157
#1  0x07a5aedc in fbRasterizeEdges (buf=0x1f261000, bpp=8, width=620,
stride=155, l=0xbfffc964, r=0xbfffc98c, t=2147297962, b=2147481462) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/libpixman/src/fbedge.c:299
#2  0x07a3f95c in fbRasterizeTrapezoid (pPicture=0x1c3dd320,
trap=0x1a1d8708, x_off=-390, y_off=0) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/libpixman/src/fbtrap.c:137
#3  0x07a22b8c in _cairo_pixman_add_trapezoids (dst=0x1c3dd320, x_off=-390,
y_off=0, traps=0x1a1d8708, ntraps=373) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/libpixman/src/ictrap.c:210
#4  0x07a100e0 in _cairo_image_surface_composite_trapezoids
(operator=CAIRO_OPERATOR_OVER, pattern=0xbfffce8c, abstract_dst=0x1c3f2310,
antialias=CAIRO_ANTIALIAS_DEFAULT, src_x=390, src_y=0, dst_x=390, dst_y=0,
width=620, height=744, traps=0x1a1d8000, num_traps=418) at
/Users/joro/inst/firefox20/mozilla/gfx/cairo/cairo/src/cairo-image-surface.c:781

Comment 8

[Bob Clary [:bc] (inactive)]

I couldn't reproduce a crash in a recent debug trunk on macppc, linux or windows.

Comment 9

[Jesse Ruderman]

No crash for me.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061027 Minefield/3.0a1

Comment 10

[georgi - hopefully not receiving bugspam]

(In reply to comment #8)
> I couldn't reproduce a crash in a recent debug trunk on macppc

trunk never crashed for me. 2.0 (1.8) BRANCH crashes for me with old profile but not with clean profile.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'm worried about this potentially stomping on memory; I'd like to get it running under Purify.  (And maybe it's only causing a crash because of something specific in that profile, otherwise it's just scribbling over memory that might cause a crash later on?)  I'll try this week, assuming I can get Purify to cooperate.

Comment 12

[georgi - hopefully not receiving bugspam]

(In reply to comment #11)
>  (And maybe it's only causing a crash because of
> something specific in that profile, otherwise it's just scribbling over memory
> that might cause a crash later on?)  

this is possible. it is also possible that the bug is invalid.

for linux debugging valgrind is nice - http://valgrind.org/.
valgrind is quite slow, but still usefull (doesn't need recompilation, runtime only. some tuning for reducing library noise helps)

doesn't seem to have a macosx port though.

Comment 13

[georgi - hopefully not receiving bugspam]

in the crashing profile the testcase is sensitive to the numbers - some values don't produce a crash.
in the non crashing profile fuzzing the testcase doesn't produce a crash.

Comment 14

[georgi - hopefully not receiving bugspam]

on linux valgrind doesn't detect memory problems with this one

Comment 15

[Johnny Stenback (:jst)]

This looks exploitable, and needs an owner. Handing this to Vlad for now, but please feel free to move this if there's a better owner.

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Fixing this might require either (or both of):

- Upgrading cairo on the branch

- Changing SVG to use the image surface on the branch

tor, how hard would the latter be?

Comment 17

[tor]

(In reply to comment #16)
> Fixing this might require either (or both of):
> 
> - Upgrading cairo on the branch
> 
> - Changing SVG to use the image surface on the branch
> 
> tor, how hard would the latter be?

Not hard - it would just involve refreshing the patch in bug 311565 to the current branch code.  Switching to the image backend is actually a performance optimization which was turned down for ff1.5, and somehow didn't end up on the list of things to merge into ff2.

Comment 18

[tor]

Attachment: switch win32 and os-x to image surface

Update patch from bug 311565.

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm, does it actually fix the crash?

Comment 20

[tor]

(In reply to comment #19)
> Hmm, does it actually fix the crash?

Well, the testcase doesn't crash with the patch, but then neither does it with 2.0.0.4. OS-X 10.4.9 G4.

Comment 21

[georgi - hopefully not receiving bugspam]

i don't crash anymore with this one

Comment 22

[Damon Sicore (:damons)]

Are we going to land this?  Is this fixed?

Comment 23

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This should get landed.

Comment 24

[Damon Sicore (:damons)]

Just spoke with Vlad about this, and we're wondering why this hasn't landed.  Tor, can you land this?

Comment 25

[tor]

I didn't land it because I couldn't reproduce the crash with non-patched builds.

Comment 26

[Damon Sicore (:damons)]

Is this something we need to get QA on, or are we satisfied that it isn't reproducable?

Comment 27

[tor]

Sure, some QA attempt to reproduce the problem would be good.

Comment 28

[Tim Riley [:timr]]

I hang for 10 minutes on Win XP
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 )
This is reproducible.  CPU hit 50% and mem usage bounces around wildly between 37M and 354M

The tab seems to hang indefinitely on Mac OS.  It keeps the attachment ID in the tab itself.  But the page is blank.  CPU and mem usage is does _not_ bounce around wildly.
(Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007092604 Minefield/3.0a9pre)

But no crash.

Does anyone have a patched build handy that I can test?

Comment 29

[Carsten Book [:Tomcat]]

no hang or crash for with the testcase from this bug and Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007092605 Minefield/3.0a9pre ID:2007092605 on Windows XP x64 Sp2 and the 2007092704 build on intel mac 

Comment 30

[Tim Riley [:timr]]

I also tried the latest trunk on XP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092705 Minefield/3.0a9pre
This seems to work find.  I get a blank page in the tab.  But no hang or crash.

Comment 31

[Samuel Sidler (old account; do not CC)]

I see no hang or crash using 2.0.0.7 on Mac OS X, but I *do* have a slight hang using 2.0.0.7 on Windows 2k. It lasts for a bit under a minute and then recovers.

I see no hang or crash using the lastest trunk nightly Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007092704 Minefield/3.0a9pre on either Windows 2k or Mac OS X.

Note that on Mac, branch and trunk, and Windows trunk, the testcase displays nothing, but on Windows branch I see the red and black testcase.

Comment 32

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We need to either land this or INVALID this.  This is also not blocking 1.9+; it doesn't happen on trunk.

Comment 33

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Not sure why this was assigned to me -- as I said earlier, either tor's patch needs to be landed on the 1.8 branch, or the bug needs to be marked INVALID/WONTFIX...

Comment 34

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

This is WFM, as I can tell from my reading of this bug.