Bug 4505

Summary: segmentation fault when running gtk (with cairo) applications at Depth 8
Product: cairo Reporter: Dumitru Sipos <dumitru.sipos>
Component: image backendAssignee: Carl Worth <cworth>
Status: RESOLVED DUPLICATE QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: critical    
Priority: high CC: kurt, matthieu.herrb, nodes
Version: 1.0.2   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Dumitru Sipos 2005-09-19 02:35:20 UTC
on Solaris 2.8 gtk applications crash with a SEGMENTATION FAULT.

the problem seems to be located inside file fbcompose.c ($XdotOrg:
xc/programs/Xserver/fb/fbcompose.c,v 1.5 2005/01/13 20:49:21 sandmann Exp $)

inside method  "void fbFetch(PicturePtr pict, int x, int y, int width, CARD32
*buffer)"
 the pointer "fetch" ("fetchProc fetch = fetchProcForPicture(pict);") is not
checked againt zero value and at line 2673 the call: "fetch(bits, x, width,
buffer, indexed);" causes a segmentation fault.

software config:
cairo-1.0.0
gtk+-2.8.3
pango-1.10.0
renderext-0.9
libXrender-0.9.0


backtrace:


      76 Program received signal SIGSEGV, Segmentation fault.
      77 0x00000000 in ?? ()
      78 #0  0x00000000 in ?? ()
      79 #1  0xfe9de844 in fbFetch (pict=0x14d840, x=0, y=1366080, width=0,
buffer=0x35)
      80     at fbcompose.c:2673
      81 #2  0xfe9e0c7c in fbCompositeRect (data=0xffbe44f8,
scanline_buffer=0xffbe4518)
      82     at fbcompose.c:3565
      83 #3  0xfe9e1428 in pixman_compositeGeneral (op=4290659576, pSrc=0x14d930, 
      84     pMask=0x14d520, pDst=0x35, xSrc=152, ySrc=12, xMask=0, yMask=0,
xDst=0, 
      85     yDst=0, width=53, height=9) at fbcompose.c:3677
      86 #4  0xfe9b5958 in _cairo_image_surface_composite (
      87     operator=CAIRO_OPERATOR_OVER, src_pattern=0xffbeab88, 
      88     mask_pattern=0xffbea778, abstract_dst=0x14d8b8, src_x=152, src_y=12, 
      89     mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=53, height=9)
      90     at cairo-image-surface.c:595
      91 #5  0xfe9baee4 in _fallback_composite (operator=CAIRO_OPERATOR_OVER, 
      92     src=0xffbeab88, mask=0xffbea778, dst=0x0, src_x=152, src_y=12,
mask_x=0, 
      93     mask_y=0, dst_x=152, dst_y=12, width=53, height=9) at
cairo-surface.c:800
      94 #6  0xfe9c43c8 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x18, 
      95     operator=CAIRO_OPERATOR_OVER, pattern=0xffbeab88, surface=0x149ce8, 
      96     source_x=152, source_y=12, dest_x=152, dest_y=12, width=53, height=9, 
      97     glyphs=0x14ce88, num_glyphs=7) at cairo-ft-font.c:2048
      98 #7  0xfe9b0fa4 in _cairo_scaled_font_show_glyphs (scaled_font=0xdc200, 
      99     operator=CAIRO_OPERATOR_OVER, pattern=0xffbeab88, surface=0x149ce8, 
     100     source_x=152, source_y=12, dest_x=152, dest_y=12, width=53, height=9, 
     101     glyphs=0x14ce88, num_glyphs=7) at cairo-font.c:929
     102 #8  0xfe9b422c in _cairo_gstate_show_glyphs_draw_func (closure=0xffbeab60, 
     103     operator=CAIRO_OPERATOR_OVER, src=0xffbeab88, dst=0x149ce8, dst_x=0, 
     104     dst_y=0, extents=0xffbeab70) at cairo-gstate.c:2053
     105 #9  0xfe9b2f88 in _cairo_gstate_clip_and_composite (clip=0x14cdb0, 
     106     operator=CAIRO_OPERATOR_OVER, src=0xffbeab88, 
     107     draw_func=0xfe9b4144 <_cairo_gstate_show_glyphs_draw_func>, 
     108     draw_closure=0xffbeab60, dst=0x149ce8, extents=0xffbeab70)
     109     at cairo-gstate.c:1094
     110 #10 0xfe9b43ac in _cairo_gstate_show_glyphs (gstate=0x14cd20, 
     111     glyphs=0xffbeacf8, num_glyphs=7) at cairo-gstate.c:2131
     112 #11 0xfe9add80 in cairo_show_glyphs (cr=0xdbbc0, glyphs=0xffbeacf8, 
     113     num_glyphs=7) at cairo.c:2158
     114 #12 0xff2c617c in pango_cairo_renderer_get_type ()
     115    from /local/dsipos/app/lib/libpangocairo-1.0.so.0
...
Comment 1 Victor Hoover 2005-10-19 10:20:04 UTC
-----------------------------------------------------------------------------
I'm having the same problem under Solaris 8.  However, I've got two graphic
cards and two displays on a Sun Ultra-60.  Display :0 is a Creator 3D card
and display :1 is an Elite-3d.  The problem only occurs on the Creator-3D card
(the code isn't called when displaying on the Elite-3D).  X is running with
24 bit planes.  I've been working with cairo-1.0.0 but cairo-1.0.2 has the
same problem.

Some checking into the code shows that whenever fetchProcForPicture() is called,
the value of pict->format_code is 0x08010000 (which is not listed in the switch()
statement).  As a result, 0 gets returned.

gtk+-2.8.6
cairo-1.0.0
pango-1.10.1
render-0.8
xrender-0.8.3
gcc-4.0.1

Vic Hoover
-----------------------------------------------------------------------------
Comment 2 David Hollenberg 2005-12-01 11:39:46 UTC
I'm also having this same problem under Solaris 9.  In our environment,
the segmentation fault seems to occur only when running with 8 planes
(with three different graphics cards: XVR-1000, Expert3D-Lite and
single-buffered FFB1 - I think this last one is built into the motherboard).
When running with 24 planes, the segmentation fault does not occur and
gtk-demo seems to run fine.

Software configuration:
gtk+-2.8.8
cairo-1.0.2
pango-1.10.1
render-0.9
xrender-0.9.0
gcc-3.2.2
Comment 3 Victor Hoover 2005-12-06 09:08:43 UTC
(In reply to comment #1)
> -----------------------------------------------------------------------------
> I'm having the same problem under Solaris 8.  However, I've got two graphic
> cards and two displays on a Sun Ultra-60.  Display :0 is a Creator 3D card
> and display :1 is an Elite-3d.  The problem only occurs on the Creator-3D card
> (the code isn't called when displaying on the Elite-3D).  X is running with
> 24 bit planes.  I've been working with cairo-1.0.0 but cairo-1.0.2 has the
> same problem.
> 
> Some checking into the code shows that whenever fetchProcForPicture() is called,
> the value of pict->format_code is 0x08010000 (which is not listed in the switch()
> statement).  As a result, 0 gets returned.
> 
> gtk+-2.8.6
> cairo-1.0.0
> pango-1.10.1
> render-0.8
> xrender-0.8.3
> gcc-4.0.1
> 
> Vic Hoover
> -----------------------------------------------------------------------------
> 

I just double checked my setup.  The Elite3D card was configured as 24 planes
but the Creator3D (which was having the problem) was indeed configured as 8
planes.  I'll get that changed and retest.

Comment 4 Kurt Miller 2005-12-09 06:06:15 UTC
This bug also presents itself on OpenBSD/macppc. I have tracked down where the     
bad format_code is created, however I don't know the proper fix for this.     
     
The bad format_code is created in _get_image_surface() in cairo-xlib-surface.c    
around line 532 when surface->visual is not 0. I see the masks struct filled in    
with bpp = 8 alpha_mask = 0 red_mask = 0 green_mask = 0 blue_mask =0. The call   
to _CAIRO_MASK_FORMAT call returns False, then   
_cairo_image_surface_create_with_masks is called which in turn calls   
_cairo_pixman_format_create_masks which creates the format_code of   
0x8010000 which is unrecognized by fetchProcForPicture.   
   
A fix or work-around for the problem would be very much appreciated. It is 
holding up firefox 1.5 on OpenBSD.  
Comment 5 Kurt Miller 2005-12-13 02:53:49 UTC
Changed to All Hardware, All OS, Version 1.0.2 and Summary to better reflect 
the problem. 
 
It is very easy to reproduce the segfault on any hardware/os combo. Just set 
your Depth to 8, ssh -X localhost and attempt to run any gtk+2 application 
(firefox 1.5, gftp, cssed, etc). So far I have reproduced it on spark64, macppc 
and i386. 
Comment 6 Kurt Miller 2005-12-20 01:43:48 UTC
The problem has been isoloated to using a PseudoColor Visual with a card driver  
that doesn't support the RENDER extension. Depth 8 defaults to a PseudoColor 
Visual. To reproduce on any platform, any driver, just set DefaultDepth 8 and 
add this to turn off RENDER:  
  
Section "Extensions"  
        Option "RENDER" "disable"  
EndSection  
 
Comment 7 Dom Lachowicz 2006-01-08 04:16:29 UTC
*** Bug 5520 has been marked as a duplicate of this bug. ***
Comment 8 Christoph Nodes 2006-02-01 20:10:16 UTC
We are having the same problems here under i686-pc-linux-gnulibc2. However, I
cannot give any additional information, but I agree with Kurt Miller: We also
would very much appreciate a fix or work-around since we'd like to migrate to
the newest gtk+ on our 50 linux machines.

I have tried

gtk+-2.8.10
pango-1.10.2
cairo-1.0.2

my backtrace looks the same.


Christoph Nodes,
BFW Werner Völk GmbH
Comment 9 Knut Hellebo 2006-03-06 21:31:47 UTC
Seems like 5804 is a duplicate of this bug....
Comment 10 Eric Faurot 2006-04-28 03:28:28 UTC
(In reply to comment #9)
> Seems like 5804 is a duplicate of this bug....

This issue is probably the same as 4945.
I have written a patch that fixes it. see:

https://bugs.freedesktop.org/show_bug.cgi?id=4945

Kurt: I have posted it on the openbsd ports ML a while back.
Comment 11 Behdad Esfahbod 2006-06-13 22:57:35 UTC

*** This bug has been marked as a duplicate of 4945 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.