Bug 207582

Here's the block of code with the assertion you've managed to trigger:

    switch (ximage->bits_per_pixel) {
    case 1:
        unit_bytes = ximage->bitmap_unit / 8;
        break;
    case 8:
    case 16:
    case 32:
        unit_bytes = ximage->bits_per_pixel / 8;
        break;
    default:
        /* This could be hit on some uncommon but possible cases,
         * such as bpp=4. These are cases that libpixman can't deal
         * with in any case.
         */
        ASSERT_NOT_REACHED;
    }

I've never felt very comfortable with the claims of that comment, but this is
the first report I've heard of somebody tripping over the problem. Can you
describe for me some of the details of the X server you are talking to here?

Perhaps the easiest way to do that would be:

DISPLAY=localhost:10.0 xdpyinfo

and then attach the output to this bug report.

Thanks,

-Carl

Here you go.

]# xdpyinfo
name of display:    localhost:10.0
version number:    11.0
vendor string:    Hummingbird Ltd.
vendor release number:    9000
maximum request size:  4194300 bytes
motion buffer size:  1
bitmap unit, bit order, padding:    8, MSBFirst, 32
image byte order:    MSBFirst
number of supported pixmap formats:    4
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 12, bits_per_pixel 12, scanline_pad 32
    depth 24, bits_per_pixel 24, scanline_pad 32
keycode range:    minimum 8, maximum 254
focus:  PointerRoot
number of extensions:    12
    BIG-REQUESTS
    DOUBLE-BUFFER
    Extended-Visual-Information
    HCL-DOS-Access
    HCLMISC
    HCLxperf
    LBX
    SECURITY
    SHAPE
    TOG-CUP
    XC-MISC
    XInputExtension
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1024x745 pixels (320x232 millimeters)
  resolution:    81x82 dots per inch
  depths (4):    1, 8, 12, 24
  root window id:    0x35
  depth of root window:    24 planes
  number of colormaps:    minimum 8183, maximum 8183
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store WHEN MAPPED, save-unders NO
  largest cursor:    32x32
  current input event mask:    0x420000
    StructureNotifyMask      PropertyChangeMask
  number of visuals:    4
  default visual id:  0x24
  visual:
    visual id:    0x21
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x22
    class:    StaticGray
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x23
    class:    PseudoColor
    depth:    12 planes
    available colormap entries:    4096
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x24
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits

Thank you,

The essential piece of information from that report is the following:

supported pixmap formats:
...
    depth 24, bits_per_pixel 24, scanline_pad 32

The problem here is that the Hummingbird X server is using 24 bits per pixel for
depth 24 pixmaps while cairo is expecting the more common 32 bits per pixel, as
can be seen with an Xorg server for example:

supported pixmap formats:
...
    depth 24, bits_per_pixel 32, scanline_pad 32

It's perhaps not a huge amount of work to fix, but it would definitely require
some understanding of how the Hummingbird X server is packing the bytes,
(particuarly with respect to endian-ness, which is what the cairo code is trying
to handle here... a difference in byte order between the X image it received and
 and the native endian-ness of the host platform).

I'm retitling the bug to capture what we now understand about what triggers the
bug, (and in doing so, it's not very surprising that we hadn't heard about this
bug yet).

-Carl

I get similar error with Solaris X server.

Steps to Reproduce:
1. SSH to RHEL5 Server with X11 tunneling enabled.
2. Issue some of system-config-* command.

uname in Solaris server:

hydra:~$uname -a
SunOS hydra 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-280R

Xdpyinfo in RHEL5-beta:

[root@test ~]# xdpyinfo
name of display:    localhost:10.0
version number:    11.0
vendor string:    Sun Microsystems, Inc.
vendor release number:    6620
maximum request size:  262140 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, MSBFirst, 32
image byte order:    MSBFirst
number of supported pixmap formats:    3
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 254
focus:  window 0x78009b, revert to Parent
number of extensions:    33
    AccessX
    Adobe-DPS-Extension
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DPSExtension
    Extended-Visual-Information
    FBPM
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    Multi-Buffering
    RECORD
    SECURITY
    SHAPE
    SUN_ALLPLANES
    SUN_DGA
    SUN_OVL
    SUN_SME
    SYNC
    SolarisIA
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XEVIE
    XFIXES
    XIE
    XInputDeviceEvents
    XInputExtension
    XTEST
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1280x1024 pixels (361x289 millimeters)
  resolution:    90x90 dots per inch
  depths (3):    1, 24, 32
  root window id:    0x2e
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x22
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store YES, save-unders YES
  largest cursor:    64x64
  current input event mask:    0xfa0033
    KeyPressMask             KeyReleaseMask           EnterWindowMask
    LeaveWindowMask          StructureNotifyMask      SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask          PropertyChangeMask
    ColormapChangeMask
  number of visuals:    1
  default visual id:  0x20
  visual:
    visual id:    0x20
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits

I forgot error message:

[root@test ~]# system-config-date
Error: Cairo does not yet support the requested image format:
        Depth: 32
        Alpha mask: 0x00000000
        Red   mask: 0x000000ff
        Blue  mask: 0x0000ff00
        Green mask: 0x00ff0000
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
python2: cairo-image-surface.c:144: _cairo_format_from_pixman_format: Assertion 
`NOT_REACHED' failed.

I am seeing the same error when using  Xvnc based on XFree86-3.3. I need this
for an old app that cannot handle more than 8bit colour and must have backing
store(which modern versions of Xorg do not support) available.

Xlib:  extension "RANDR" missing on display "host-a:1.0"


Error: Cairo 1.2.6 does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red   mask: 0x00000000
        Green mask: 0x00000000
        Blue  mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
bug-buddy: cairo-image-surface.c:201: _cairo_format_from_pixman_format:
Assertion `NOT_REACHED' failed.

bug c->xlib.lock

This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.

Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days