Bug 7294

Created attachment 6011 [details]
Stack trace log

A problem is, when I pass '--enable-xlib=no' to disable this
feature, libgdk-x11-2.0.so doesn't run a program due to
missing function.

An another problem, I'm not sure X Render library (0.9.0)
can work properly on IRIX (though it's compilable).

The last, if that's duplicate, slap me and close this bug account.

Thanks for your reading.

Ouch, I just found '1.1.10' at the version selector...

1.1.10 is available as a version---it was just hiding between 1.1.1 and 1.1.2.

As for the bug, I'd like to collect some information from you:

1) X server version information (should appear in the first few lines of
xdpyinfo output)

2) Processor type, (including little endian vs. big endian)

3) What information do you have about how previous versions of cairo behave on
the same system? 

-Carl

Created attachment 6012 [details]
Output of xdpyinfo

Hmm, I feel I should leave more details on my machine,
it's big-endian and... well, I don't know what else
I'm supposed to.

Created attachment 6013 [details]
Output of glxinfo

Probably, this output is useless (cairo-glitz),
I'll upload however.

Wow, your comment already that I didn't notice.

Re-titling the bug to make it more clear.

Any information about how cairo behaved in versions prior to 1.1.10?

It wouldn't have crashed here since that assertion was introduced between 1.1.8
and 1.1.10. But other possibilites are:

1) It crashed somewhere else

2) It didn't crash but some colors are wrong (such as swapped red and blue channels)

3) It worked correctly

Please let me know.

-Carl

(In reply to comment #4)

> 1.1.10 is available as a version---it was just hiding between
> 1.1.1 and 1.1.2.
>
> As for the bug, I'd like to collect some information from you:
> 
> 1) X server version information (should appear in the first
> few lines of xdpyinfo output)
> 
> 2) Processor type, (including little endian vs. big endian)

Your comments and my feeling were just crossing.

> 3) What information do you have about how previous versions of
> cairo behave on the same system? 

Does nothing IIRC, though I can't recall the exact version of
Cairo used with gtk+ apps (when I updated CVS version of gtk+
a day ago, it was version-binded to cairo >= 1.1.8, so I decided
to grab this snapshot).

(In reply to comment #8)
> Re-titling the bug to make it more clear.
> 
> Any information about how cairo behaved in versions prior
> to 1.1.10?
> 
> It wouldn't have crashed here since that assertion was introduced
> between 1.1.8 and 1.1.10. But other possibilites are:
> 
> 1) It crashed somewhere else

Nope, it was working however,
 
> 2) It didn't crash but some colors are wrong (such as
> swapped red and blue channels)

Exactly, it kept giving me `Rainbow Colours' at the certain
pane when I used Gtk-Gnutella.
 
> 3) It worked correctly

Exactly my wish.

One additional problem here, you may want to say;

  'ok, I changed some codes, can you try this?'

My answer would be;

  'Well, git itself doesn't compile on my machine (IRIX/O2)...'

If you'll give me a simple code to check or a patch against
1.1.10 (1.1.11), I'll be willing to try.

If I understand correctly what you wrote above, it indicates that cairo has
never worked with X server visuals that give a BGR rather than RGB pixel order,
(that is R,G,B masks of 0xff, 0xff00, 0xff0000 rather than 0xff0000, 0xff00, 0xff).

So the new behavior in 1.1.10 is simply "truth in advertising" in that cairo now
detects this case, announces the missing support, and refuses to proceed.

If someone were interested in fixing this, the work involved would be to fix the
_get_image_surface and _draw_image_surfaces in src/cairo-xlib-surface.c to
convert the image data between the format of the X server and one of the
supported cairo formats, (for example, in this particular case swapping red and
blue channels to arrive at CAIRO_FORMAT_ARGB32).

There's probably enough support in pixman already that all that may be necessary
is to create pixman images in both formats and then perform a pixman composite
operation from one to the other to perform the necessary conversion. Once that
code is in place, cairo would then have support for arbitrary X visuals.

Created attachment 6014 [details] [review]
Patch for IRIX

Jusr remembered, the patch uploaded is needed to compile pixman
on IRIX 6.5, although not sure whether the other places also
need modyfing.

or `#ifdef HAVE_INTTYPES_H' simply...

FYI, now I have working git suites, will submit a patch
(against the latest version) as it seems nobady will try.

Carl, thanks for your hints.

Created attachment 6094 [details] [review]
Uncertain BGR support patch

While I'll upload this workaround patch, it requires a patch against
XRender itself (later upload). If I'm not so wrong it should be done
by swapped coloour mask (aka little hack), hey developers, I need your
opinions.

Thanks

Created attachment 6095 [details] [review]
XRender BGR support patch

Here it is, I'm not sure that XRender itself needs to be modified.
Anyway, I'd like to report it works here.

Created attachment 6166 [details] [review]
BGR support patch

A patch against the latest git repository, it seems working
on Alpha/Digital UNIX.

*** Bug 7408 has been marked as a duplicate of this bug. ***

*** Bug 7479 has been marked as a duplicate of this bug. ***

(In reply to comment #16)
> While I'll upload this workaround patch, it requires a patch against
> XRender itself (later upload). If I'm not so wrong it should be done
> by swapped coloour mask (aka little hack), hey developers, I need your
> opinions.

Thanks for contributing a patch here.

I don't think this is the direction we want to go in though. Extending the
Render extension is not likely to fly at all.

Instead, what we need here in cairo is actually pretty simple. When we detect
that the X server is using a format that cairo doesn't support directly, all we
need to do is to create a Render picture for that format, (which we know the X
server will support), also create a Render picture in a format that cairo does
support. Then a simple call to XRenderComposite with an operator of SOURCE will
allow the X server to use its existing code for the format conversion, and all
should then work just fine.

I plan to start working on a patch for this, but if someone can beat me to it,
then that would be just fine with me.

-Carl

Created attachment 6191 [details]
xdpyinfo output of sunray on linux

hi, we run a sunray server on a linux x86 machine and i believe we just got hit
by this bug. when trying to run firefox, i get this message:

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
firefox-bin:
/home/dajobe/dev/debian/cairo/libcairo-1.2.0/src/cairo-image-surface.c:144:
_cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
Abort

the machine is a dual opteron running debian unstable, kernel 2.6.16 (debian
image). the problem started once we upgraded to cairo 1.2.0 (debian package,
version 1.2.0-3) from 1.0.4 (also debian package, version 1.0.4-2). before the
upgrade, we had no problems, no weird colors, no crashes (at least that could
be blamed on cairo). downgrading back to 1.0.4 fixes the problem.

the output of xdpyinfo is attached. any other info i could provide you with?
thanks!
ricardo

*** Bug 7508 has been marked as a duplicate of this bug. ***

*** Bug 7561 has been marked as a duplicate of this bug. ***

*** Bug 7563 has been marked as a duplicate of this bug. ***

*** Bug 7554 has been marked as a duplicate of this bug. ***

*** Bug 7587 has been marked as a duplicate of this bug. ***

*** Bug 7610 has been marked as a duplicate of this bug. ***

Created attachment 6331 [details] [review]
Add format conversion to xlib Get/PutImage paths

Here's a preliminary patch. It's rather ugly in a few ways:

1) It duplicates code where it should be sharing
2) The format conversion code truncates where it could do rounding.

But I would be interested to hear feedback from people who are hitting this
bug. Does this patch help? Does it give correct results?

-Carl

(In reply to comment #29)
> Created an attachment (id=6331) [edit]
> Add format conversion to xlib Get/PutImage paths
> 
> But I would be interested to hear feedback from people who are hitting this
> bug. Does this patch help? Does it give correct results?

It runs, but does not yield correct colours. Notably there's a lot of teal artifacts.

http://ubb.ca/~nicoya/vimcairo.png

> Here's a preliminary patch. It's rather ugly in a few ways:
> 
> But I would be interested to hear feedback from people who are hitting this
> bug. Does this patch help? Does it give correct results?

With an Exceed X-server it's now possible to start applications. But the
background color of text ist wrong (see http://www.hpke.de/tmp/cairo.jpg)

My workaround was to set Xvnc to RGB888. I have no idea why its default is BGR. 

Created attachment 6339 [details] [review]
Add format conversion to xlib Get/PutImage paths [rev-1]

I found a couple of bugs in my first patch, for which an updated patch is
attached. The important bug fixes in this version are copied below. But it
doesn't look like either of these fixes would explain the cyan backgrounds seen
in the two recent reports. But do try out this newer patch and let me know how
it goes.

The cyan results look like something in either _get_image_surface or
_draw_image_surface is zeroing out the red channel. I have not been able to
reproduce this behavior yet, nor have I been able to find the bug.

I'm currently using Xvnc for testing this bug, like so:

Xvnc -ac -depth 24 -pixelformat bgr888 -SecurityTypes None -localhost :2

If someone can find a similar approach that succefully replicates the cyan
behavior bug, that would be helpful. Otherwise, if someone who is seeing the
cyan behavior could step through the two functions I mentioned above in a
debugger and see where the red channel is being set to 0 that would also be
very helpful. Please let me know if you are interested in doing that and need
some help in doing it.

-Carl

diff -u b/src/cairo-xlib-surface.c b/src/cairo-xlib-surface.c
--- b/src/cairo-xlib-surface.c
+++ b/src/cairo-xlib-surface.c
@@ -539,6 +539,12 @@
	masks->green_mask = 0x0000ff00;
	masks->blue_mask  = 0x000000ff;
	return;
+    case CAIRO_FORMAT_RGB16_565:
+	masks->alpha_mask = 0;
+	masks->red_mask   = 0xf800;
+	masks->green_mask = 0x07e0;
+	masks->blue_mask  = 0x001f;
+	return;
     case CAIRO_FORMAT_A8:
	masks->alpha_mask = 0xff;
	masks->red_mask   = 0;
@@ -927,7 +928,7 @@

	_cairo_format_masks_from_format (&image_format_masks, image_format);

-	alpha_shift = _right_shift_amount (image_format_masks.alpha_mask,
masks.red_mask);
+	alpha_shift = _right_shift_amount (image_format_masks.alpha_mask,
masks.alpha_mask);
	red_shift = _right_shift_amount (image_format_masks.red_mask,
masks.red_mask);
	green_shift = _right_shift_amount (image_format_masks.green_mask,
masks.green_mask);
	blue_shift = _right_shift_amount (image_format_masks.blue_mask,
masks.blue_mask);

(In reply to comment #33)
> I found a couple of bugs in my first patch, for which an updated patch is
> attached. The important bug fixes in this version are copied below. But it
> doesn't look like either of these fixes would explain the cyan backgrounds seen
> in the two recent reports. But do try out this newer patch and let me know how
> it goes.

Behaviour observed is basically identical to the previous patch. Works, but teal.

I might poke around at the code at some point if I find the time.

*** Bug 7690 has been marked as a duplicate of this bug. ***

Don't know if it's relevant, but I've tried running gtk applications on FreeBSD
with gtk-2.8 and cairo-1.0.2 under X-Win32, and they work, while gtk-2.8 +
cairo-1.2.0 on debian fails with "Cairo does not yet support the requested image
format" message (same WinXP machine with X-Win32 in both cases).

*** Bug 7710 has been marked as a duplicate of this bug. ***

(In reply to comment #36)
> Don't know if it's relevant, but I've tried running gtk applications on FreeBSD
> with gtk-2.8 and cairo-1.0.2 under X-Win32, and they work, while gtk-2.8 +
> cairo-1.2.0 on debian fails with "Cairo does not yet support the requested image
> format" message (same WinXP machine with X-Win32 in both cases).

The old versions of cairo were definitely not behaving correctly, (a program
could be written to demonstrate the failure). But due to some lucky accidents,
(such as symmetric operations being applied to all color channels), many
programs did not demonstrate the bug.

I know there are a lot of people watching this bug, and I'd like to ask for some
help in characterizing the "cyan side-effect" in the patch I've proposed.

I haven't seen the cyan background for text when running with Xvnc. And I also
have received a report (through email) that the patch works without any cyan
side-effect in a Sun Ray environment.

Can everybody who has tested the patch please report what X server they are
using and whether the bad cyan side-effect shows up. Let's say "cyan" vs. "no cyan".

Thanks,

-Carl

PS. Keith Packard was as appalled by my patch as I thought he might be. I think
he found it disgusting enough that he might have been convinced to rewrite a
cleaner version. Let's hope so. (But if it doesn't appear soon, and we don't
find the cyan bug in my patch, then I may be landing it soon---I definitely want
to get a 1.2.2 release made soon to fix this bug for as many people as possible.)

(In reply to comment #39)
> Can everybody who has tested the patch please report what X server they are
> using and whether the bad cyan side-effect shows up. Let's say "cyan" vs. "no cyan".

I get the cyan artifacts, and I'm using Xsgi. It uses 24-bit depth and 32-bpp, perhaps the bug doesn't 
show up on 24-bit depth and 24-bpp.

name of display:    jupiter.fast:0.0
version number:    11.0
vendor string:    Silicon Graphics
vendor release number:    6600
maximum request size:  262140 bytes
motion buffer size:  0
bitmap unit, bit order, padding:    32, MSBFirst, 32
image byte order:    MSBFirst
number of supported pixmap formats:    6
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 12, bits_per_pixel 16, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
[...]
  depth of root window:    24 planes
[...]
  number of visuals:    10
  default visual id:  0x28
[...]
  visual:
    visual id:    0x28
    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

*** Bug 7711 has been marked as a duplicate of this bug. ***

*** Bug 7712 has been marked as a duplicate of this bug. ***

I am running on solaris/sparc, and hit this since the new gtk demands the latest
cairo. Anyway I haven't yet tried the patch mentioned previosly, but I just
hacked the code with


/* Try to recover a cairo_format_t from a pixman_format
 * by looking at the bpp and masks values. */
static cairo_format_t
_cairo_format_from_pixman_format (pixman_format_t *pixman_format)
{
    int bpp, am, rm, gm, bm;

    pixman_format_get_masks (pixman_format, &bpp, &am, &rm, &gm, &bm);

    /*fprintf(stderr, "[sws cairo] bpp %d\n", bpp);*/

    switch (bpp) {
    case 32:
	if (am == 0xff000000 &&
	    rm == 0x00ff0000 &&
	    gm == 0x0000ff00 &&
	    bm == 0x000000ff)
	    return CAIRO_FORMAT_ARGB32;
	if (am == 0x0 &&
	    rm == 0x00ff0000 &&
	    gm == 0x0000ff00 &&
	    bm == 0x000000ff)
	    return CAIRO_FORMAT_RGB24;

        /* sws try this rather than crash */
        fprintf(stderr, "[sws cairo] bpp %d, faking it\n", bpp);
        return CAIRO_FORMAT_RGB24;

- At least firefox, mozilla don't crash
- I don't see any color problems; the crash seems to be triggered by grey  
popups, and they still look grey to me   

*** Bug 7714 has been marked as a duplicate of this bug. ***

(In reply to comment #43)
> I am running on solaris/sparc, and hit this since the new gtk demands the 
latest
> cairo. Anyway I haven't yet tried the patch mentioned previosly, but I just
> hacked the code with
> /* Try to recover a cairo_format_t from a pixman_format
>  * by looking at the bpp and masks values. */
> static cairo_format_t
> _cairo_format_from_pixman_format (pixman_format_t *pixman_format)
> {
>     int bpp, am, rm, gm, bm;
>     pixman_format_get_masks (pixman_format, &bpp, &am, &rm, &gm, &bm);
>     /*fprintf(stderr, "[sws cairo] bpp %d\n", bpp);*/
>     switch (bpp) {
>     case 32:
> 	if (am == 0xff000000 &&
> 	    rm == 0x00ff0000 &&
> 	    gm == 0x0000ff00 &&
> 	    bm == 0x000000ff)
> 	    return CAIRO_FORMAT_ARGB32;
> 	if (am == 0x0 &&
> 	    rm == 0x00ff0000 &&
> 	    gm == 0x0000ff00 &&
> 	    bm == 0x000000ff)
> 	    return CAIRO_FORMAT_RGB24;
>         /* sws try this rather than crash */
>         fprintf(stderr, "[sws cairo] bpp %d, faking it\n", bpp);
>         return CAIRO_FORMAT_RGB24;
> - At least firefox, mozilla don't crash
> - I don't see any color problems; the crash seems to be triggered by grey  
> popups, and they still look grey to me   

-------------------
Sam - I used this fix for the crashing issue yet what was your success rate 
when you ran 'gmake check' ? I got this error with the SVG part on this
platform SunOS tester1 5.8 Generic_117350-34 sun4u sparc SUNW,Sun-Blade-1000 
using X11R6 (XSun) v6.4.1:

clip-nesting-svg-argb32 [0]:    FAIL
clip-nesting-svg-argb32 [25]:   FAIL
clip-nesting-svg-rgb24 [0]:     FAIL
clip-nesting-svg-rgb24 [25]:    FAIL
FAIL: clip-nesting

svg-arg32 and svg-rgb24 fail in almost every test.

Ken Mays

(In reply to comment #45)
> Sam - I used this fix for the crashing issue yet what was your success rate 
> when you ran 'gmake check' ? I got this error with the SVG part on this
> platform SunOS tester1 5.8 Generic_117350-34 sun4u sparc SUNW,Sun-Blade-1000 
> using X11R6 (XSun) v6.4.1:
> 
> clip-nesting-svg-argb32 [0]:    FAIL
> clip-nesting-svg-argb32 [25]:   FAIL
> clip-nesting-svg-rgb24 [0]:     FAIL
> clip-nesting-svg-rgb24 [25]:    FAIL
> FAIL: clip-nesting
> 
> svg-arg32 and svg-rgb24 fail in almost every test.

Have you looked out the output and diff images for these?

Testing the SVG backend is something that has a strong dependence on the version
of librsvg you are using. In fact, it may be that you can only get the SVG
backend to pass the test suite by using an unreleased version of librsvg from CVS.

Meanwhile, as mentioned above cairo 1.0.2 "works" with BGR X servers where
there's simply no check at all in the place that cairo 1.2.0 now has the
infamous assertion.

So I would expect that Sam's hack "works" as well as cairo 1.0.2 does.

-Carl

(In reply to comment #45)
I haven't gotten make check to work yet... sighandler_t doesn't seem to exist
and poppler doesn't want to link yet...

Anyway my hack is just that - not guaranteed to work as it clearly subverts the
intentions of the code. It does seem to be functional for me. I don't know
enough about the code to know how much damage it could do. So don't use it for
anything but an experiment. That said, it sounds like reverting to 1.0.4 is safe
either.

I tried the patch from comment #33 and got cyan background on text labels
(http://munt.mine.nu:8080/files/cairo-xwin32.png). The configuration is: client
- debian with cairo from git and the patch applied; server - X-Win32 on windows XP.
Some xdpyinfo output:

name of display:    192.168.3.5:0.0
version number:    11.0
vendor string:    StarNet Communications Corp.
vendor release number:    49
maximum request size:  262140 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    8, MSBFirst, 16
image byte order:    MSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 16
    depth 4, bits_per_pixel 4, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
[...]
  depth of root window:    24 planes
[...]
  number of visuals:    2
  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
[...]

(In reply to comment #46)
> (In reply to comment #45)
> > Sam - I used this fix for the crashing issue yet what was your success rate 
> > when you ran 'gmake check' ? I got this error with the SVG part on this
> > platform SunOS tester1 5.8 Generic_117350-34 sun4u sparc SUNW,Sun-Blade-
1000 
> > using X11R6 (XSun) v6.4.1:
> > 
> > clip-nesting-svg-argb32 [0]:    FAIL
> > clip-nesting-svg-argb32 [25]:   FAIL
> > clip-nesting-svg-rgb24 [0]:     FAIL
> > clip-nesting-svg-rgb24 [25]:    FAIL
> > FAIL: clip-nesting
> > 
> > svg-arg32 and svg-rgb24 fail in almost every test.
> Have you looked out the output and diff images for these?
> Testing the SVG backend is something that has a strong dependence on the 
version
> of librsvg you are using. In fact, it may be that you can only get the SVG
> backend to pass the test suite by using an unreleased version of librsvg from 
CVS.
> Meanwhile, as mentioned above cairo 1.0.2 "works" with BGR X servers where
> there's simply no check at all in the place that cairo 1.2.0 now has the
> infamous assertion.
> So I would expect that Sam's hack "works" as well as cairo 1.0.2 does.
> -Carl


Carl, 

I had librsvg 2.8.1 which now I know doesn't work (i.e. doesn't pass make check)
with cairo 1.2.0. I'm going to use librsvg 2.15.0 and I've applied your patches 
with compile cairo 1.2.0. I'll open a separate bug to track issues I've seen 
with the 'make check' part of cairo 1.2.0 on Solaris 8.

Ken

Created attachment 6417 [details]
xdpyinfo output from Sun XSun (X11R6) v6620

Created attachment 6418 [details]
xdpyinfo output from Sun XSun (X11R6) v6620

(In reply to comment #33)
> Created an attachment (id=6339) [edit]
> Add format conversion to xlib Get/PutImage paths [rev-1]
> 
> I found a couple of bugs in my first patch, for which an updated patch is
> attached. The important bug fixes in this version are copied below. But it
> doesn't look like either of these fixes would explain the cyan backgrounds seen
> in the two recent reports. But do try out this newer patch and let me know how
> it goes.

Carl,

Seems the patch works on Sun Solaris platforms at the moment and fixed our
previous issues. 

Ken

Created attachment 6460 [details] [review]
Make cairo work like it did in 1.0 with an internal BGR format

I took a closer look at why things worked so well with cairo 1.0. It turns out
that cairo was taking advantage of mask-based format specifications in pixman
that are perfectly capable of rendering to an image surface.

We have consciously decided to advertise only a limited set of public formats
in cairo, and in particular not to allow an image surface to be created with
arbitrary masks specifiying the format.

But we can take advantage of this capability in pixman for the intermediate
image surfaces used in the fallbacks that will never be seen by the user.

This patch does that by adding explicity pixman names for BRG formats and
adding private cairo_internal_format_t names for them as well. This is a fairly
fragile approach overall, but it should be a good way of getting back to a
functional major release so that we can move forward on a cleaner fix in the
future.

I should mention that the functionality of this patch is similar to the patch
originally proposed by Daichi Kawahata, (but without any of the BGR additions
to the public API).

Please, everyone that can, try this patch out as soon as possible and comment
here to let me know how it works. Hopefully we'll have this bug fixed soon as
it's the last one preventing a 1.2.2 release.

-Carl

(In reply to comment #53)
> Created an attachment (id=6460) [edit]
> Make cairo work like it did in 1.0 with an internal BGR format
>
> Please, everyone that can, try this patch out as soon as possible and comment
> here to let me know how it works. Hopefully we'll have this bug fixed soon as
> it's the last one preventing a 1.2.2 release.

Nope, that doesn't work.

gvim: /home/nicoya/temp/cairo/libcairo-1.2.0/src/cairo-image-surface.c:522: 
_cairo_content_from_format: Assertion `NOT_REACHED' failed.
Vim: Caught deadly signal ABRT
Vim: Finished.
Aborted

(In reply to comment #54)
> Nope, that doesn't work.
> 
> gvim: /home/nicoya/temp/cairo/libcairo-1.2.0/src/cairo-image-surface.c:522: 
> _cairo_content_from_format: Assertion `NOT_REACHED' failed.

Thanks for the quick response. Would it be possible for you to generate a stack
trace from the point of failure?

Thanks,

-Carl

(In reply to comment #55)
> Thanks for the quick response. Would it be possible for you to generate a stack
> trace from the point of failure?

#0  0xb784c9e7 in raise () from /lib/tls/libc.so.6
#1  0xb784e159 in abort () from /lib/tls/libc.so.6
#2  0xb784610f in __assert_fail () from /lib/tls/libc.so.6
#3  0xb7ac3120 in cairo_font_options_create () from /usr/lib/libcairo.so.2
#4  0xb7ac33de in cairo_image_surface_get_data () from /usr/lib/libcairo.so.2
#5  0xb7ac3902 in cairo_image_surface_create () from /usr/lib/libcairo.so.2
#6  0xb7ae80ce in cairo_xlib_surface_get_display () from /usr/lib/libcairo.so.2
#7  0xb7ae84ca in cairo_xlib_surface_get_display () from /usr/lib/libcairo.so.2
#8  0xb7acb050 in cairo_surface_set_fallback_resolution ()
   from /usr/lib/libcairo.so.2
#9  0xb7accca8 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#10 0xb7accf93 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#11 0xb7acb4c1 in cairo_surface_reference () from /usr/lib/libcairo.so.2
#12 0xb7acb6a0 in cairo_surface_reference () from /usr/lib/libcairo.so.2
#13 0xb7ace1ce in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#14 0xb7ace360 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#15 0xb7acbde3 in cairo_surface_reference () from /usr/lib/libcairo.so.2
#16 0xb7ac0734 in cairo_font_options_create () from /usr/lib/libcairo.so.2
#17 0xb7abbe89 in cairo_fill_preserve () from /usr/lib/libcairo.so.2
#18 0xb7abbeb2 in cairo_fill () from /usr/lib/libcairo.so.2
#19 0xb7c3dbc4 in gdk_window_get_internal_paint_info ()
   from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb7c3de1f in gdk_window_begin_paint_region ()
   from /usr/lib/libgdk-x11-2.0.so.0
#21 0xb7dbf4fb in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#22 0xb7c3edad in gdk_window_clear_area_e () from /usr/lib/libgdk-x11-2.0.so.0
#23 0xb7c3ee8f in gdk_window_process_all_updates ()
   from /usr/lib/libgdk-x11-2.0.so.0
#24 0xb7c3ef15 in gdk_window_process_all_updates ()
   from /usr/lib/libgdk-x11-2.0.so.0
#25 0xb7a12451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#26 0xb7a13e2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#27 0xb7a17176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#28 0xb7a176f7 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#29 0xb7dbdc23 in gtk_main_iteration_do () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x0819327d in ?? ()
#31 0x00000000 in ?? ()

(In reply to comment #53)
> Created an attachment (id=6460) [edit]
> Make cairo work like it did in 1.0 with an internal BGR format

It aborts on X-Win32 too, stack trace is at
http://munt.mine.nu:8080/files/cairo.trace.

FWIW (below based on using cairo-1.2.0):

I received this error running firefox from an xterm provided by
Hummingbird Exceed on a Windows 98 PC spawned from a Linux PC
with Xorg-6.9 *before* using the BGR format patch (note that
running firefox directly from the Linux PC using GNOME and KDE
both work perfectly):

randy@rmlinux: ~/Books/BLFS/BOOK > firefox
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
firefox-bin: cairo-image-surface.c:144: _cairo_format_from_pixman_format: 
Assertion `NOT_REACHED' failed.
/opt/firefox-1.5.0.3/lib/firefox-1.5.0.3/run-mozilla.sh: line 131: 28043 
Aborted                 "$prog" ${1+"$@"}


After installing cairo using the patch (patch dated 8/4/2006), I 
receive this error:

randy@rmlinux: ~/Books/BLFS/BOOK > firefox  
firefox-bin: cairo-image-surface.c:522: _cairo_content_from_format: Assertion 
`NOT_REACHED' failed.
/opt/firefox-1.5.0.3/lib/firefox-1.5.0.3/run-mozilla.sh: line 131: 19041 
Aborted                 "$prog" ${1+"$@"}


'make check' reports the following failures:

dash-scale-pdf-argb32 [0]:      FAIL
dash-scale-pdf-argb32 [25]:     FAIL
FAIL: dash-scale 

line-width-scale-pdf-argb32 [0]:        FAIL
line-width-scale-pdf-argb32 [25]:       FAIL
FAIL: line-width-scale

ft-text-vertical-layout-image-argb32 [0]:       FAIL
ft-text-vertical-layout-image-argb32 [25]:      FAIL
ft-text-vertical-layout-image-rgb24 [0]:        FAIL
ft-text-vertical-layout-image-rgb24 [25]:       FAIL
ft-text-vertical-layout-ps-argb32 [0]:  FAIL
ft-text-vertical-layout-ps-argb32 [25]: FAIL
ft-text-vertical-layout-ps-rgb24 [0]:   FAIL
ft-text-vertical-layout-ps-rgb24 [25]:  FAIL
ft-text-vertical-layout-pdf-argb32 [0]: FAIL
ft-text-vertical-layout-pdf-argb32 [25]:        FAIL
ft-text-vertical-layout-pdf-rgb24 [0]:  FAIL
ft-text-vertical-layout-pdf-rgb24 [25]: FAIL
ft-text-vertical-layout-svg-argb32 [0]: FAIL
ft-text-vertical-layout-svg-argb32 [25]:        FAIL
ft-text-vertical-layout-svg-rgb24 [0]:  FAIL
ft-text-vertical-layout-svg-rgb24 [25]: FAIL
FAIL: ft-text-vertical-layout

lt-xlib-surface: cairo-image-surface.c:522: _cairo_content_from_format: 
Assertion `NOT_REACHED' failed.

/bin/sh: line 1: 25571 Aborted                 ${dir}$tst
FAIL: xlib-surface

========================================================================
4 of 92 tests failed
Please report to http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
========================================================================

I am not sure if the current assertion failure I'm seeing with
cairo-1.2.0 (patched using the 8/4/2006) patch provided in this
bug, belongs with this bug, or if perhaps it should be elsewhere,
but I'm listing the following in case it may be helpful.

The assertion failure I'm seeing is:

_cairo_content_from_format: Assertion `NOT_REACHED' failed.

I get this running firefox and/or the xlib-surface test of the
testsuite when using a specific X server (Hummingbird Exceed
on a Windows 98 PC).

Some specifics:

X server info (xdpyinfo)
version number:    11.0
vendor string:    Hummingbird Communications Ltd.
vendor release number:    6010

i686 PC (rather old)

version 1.0.4 of cairo works perfectly without any issues and
passes all the tests in the testsuite, as well as running any
program with cairo linked in does not exhibit issues

Created attachment 6486 [details] [review]
Make cairo work like it did in 1.0 with an internal BGR format (rev 1)

Thanks for the reports.

I apologize for sending out a patch which was so obviously broken. I tested it
here this morning with Xvnc and had the exact same problem with it that has
been reported here.

Here is an improved version that hopefully will address the problem once and
for all.

Please let me know how this latest patch works.

-Carl

Seems to work fine under VNC on Debian here.

(In reply to comment #60)
> Here is an improved version that hopefully will address the problem once and
> for all.

Works perfectly for me, no more teal and no more crashing!

Thanks for the confirmations. I've gone ahead and pushed this out now into
upstream cairo:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=9ae66174e774b57f16ad791452ed44efc2770a59

So this will be appearing very shortly in cairo 1.2.2.

Thanks to everybody for your patience with this rather obnoxious bug.

-Carl

*** Bug 7860 has been marked as a duplicate of this bug. ***

*** Bug 8172 has been marked as a duplicate of this bug. ***

*** Bug 8337 has been marked as a duplicate of this bug. ***