476554 - Fatal IO error 104 (Connection reset by peer) on X server :0.0 from XRenderCompositeTrapezoids()

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Johnny Stenback (:jst)]

Running firefox using XVnc (on Fedora Core 8), I can repeatedly crash (well, no real crash, but firefox exits), by loading the above url. By running with --sync and breaking in exit(), I got the following stack trace:

#0  exit (status=1) at exit.c:39
#1  0x00954414 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#2  0x00000001 in ?? ()
#3  0x0098f9b8 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#4  0xb7c02840 in ?? ()
#5  0x00000068 in ?? ()
#6  0x00f1c5a4 in ?? () from /lib/libc.so.6
#7  0xb7c11250 in ?? ()
#8  0xbfd384c8 in ?? ()
#9  0x00c5c071 in _XCBUnlockDisplay (dpy=0xf1c5a4) at xcb_lock.c:41
#10 0x00c55fc2 in _XIOError (dpy=0xbfd38540) at XlibInt.c:2940
#11 0x00c5be0a in _XPutXCBBuffer (dpy=0xb7c3b000) at xcb_lock.c:150
#12 0x00c5ce5f in _XSend (dpy=0xb7c3b000, data=0xf4a0bc "", size=77)
    at xcb_io.c:233
#13 0x06d1a0b6 in XRenderCompositeTrapezoids (dpy=0xb7c3b000, 
    op=<value optimized out>, src=92276937, dst=92275293, 
    maskFormat=0xb7b18460, xSrc=<value optimized out>, 
    ySrc=<value optimized out>, traps=0xabb00000, ntrap=0) at Trap.c:67
#14 0x01546185 in _cairo_xlib_surface_composite_trapezoids (
    op=CAIRO_OPERATOR_OVER, pattern=0xad0a4b30, abstract_dst=0xb00cd050, 
    antialias=CAIRO_ANTIALIAS_DEFAULT, src_x=0, src_y=6, dst_x=0, dst_y=6, 
    width=476, height=15, traps=0xac000000, num_traps=110202)
    at ../../../../../mozilla/gfx/cairo/cairo/src/cairo-xlib-surface.c:2232
#15 0x015256af in _cairo_surface_composite_trapezoids (op=CAIRO_OPERATOR_OVER, 
    pattern=0xad0a4b30, dst=0xb00cd050, antialias=CAIRO_ANTIALIAS_DEFAULT, 
    src_x=0, src_y=6, dst_x=0, dst_y=6, width=476, height=15, 
    traps=0xac000000, num_traps=110202)
    at ../../../../../mozilla/gfx/cairo/cairo/src/cairo-surface.c:1724
#16 0x0152785d in _composite_traps_draw_func (closure=0xbfd3911c, 
    op=CAIRO_OPERATOR_OVER, src=0xad0a4b30, dst=0xb00cd050, dst_x=0, dst_y=0, 
    extents=0xbfd39124)
    at ../../../../../mozilla/gfx/cairo/cairo/src/cairo-surface-fallback.c:501
#17 0x01527443 in _clip_and_composite (clip=0x0, op=CAIRO_OPERATOR_OVER, 
    src=0xad0a4b30, draw_func=0x1527739 <_composite_traps_draw_func>, 
    draw_closure=0xbfd3911c, dst=0xb00cd050, extents=0xbfd39124)
    at ../../../../../mozilla/gfx/cairo/cairo/src/cairo-surface-fallback.c:395
#18 0x01527c6d in _clip_and_composite_trapezoids (src=0xad0a4b30, 
    op=CAIRO_OPERATOR_OVER, dst=0xb00cd050, traps=0xbfd391e8, clip=0x0, 
    antialias=CAIRO_ANTIALIAS_DEFAULT)
...

Vlad says we might need to limit the number of trapezoids we send to the X server at once, but I'll let him spell out the details here, as I don't really know anything about what's going on here.

Nominating for blocking, but this might be rare enough that it's not worth it for 1.9.1...

Comment 1

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

Jeff, could we be blowing through some weird limit in Xvnc?

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Could be though I'm not sure what it would be. I can't reproduce the problem in my linux vm when not using Xvnc. I don't think that the trapezoid limit would be different with Xvnc, but I suppose it could be.

Also interesting, the backtrace claims ntrap=0. I don't know if this should believed or not.

Comment 3

[Johnny Stenback (:jst)]

FWIW, this looks like it's a non-issue with the VNC server that ships with Fedora Core 10. So this could simply be a bug in an older version of Xvnc.

Comment 4

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

Sounds good to me; Xvnc evolves differently from the core X server, so it's possible that they were behind in fixing RENDER bugs.

Comment 5

[Jesse Ruderman]

The proposed patch in bug 307254 also limited the number of trapezoids sent to the X server at a time.  Could this be a dup?

Comment 6

[Benoit Girard (:BenWa)]

Closing since we've only had one reproduction on a software version dating back to 2009 and based on Comment 3. Please re-open if the problem is reproduced.