gtk apps segfault on gnome 'Human' theme, only from XDMCP

[Daniel Allen]

On a batch of machines I just dist-upgraded from Breezy to Dapper, Firefox
(and gimp) will segfault when they are run from gnome via XDMCP
(thin-client).

It doesn't segfault from KDE via XDMCP, and it doesn't segfault from
gnome from non-XDMCP X (monitor plugged directly into server). Further, it doesn't segfault when the gnome theme is changed from 'Human' to 'LegacyHuman'.

I installed 'firefox-dbg' and run firefox -g, with the following output:

---
drallen@host:~$ firefox
Segmentation fault
drallen@host:~$ firefox -g
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
library"/lib/libthread_db.so.1".

(gdb) r
Starting program: /usr/lib/firefox/firefox-bin -a firefox
[Thread debugging using libthread_db enabled]
[New Thread 46912551651792 (LWP 7136)]
[New Thread 1082132832 (LWP 7147)]
[New Thread 1090525536 (LWP 7148)]
[New Thread 1098918240 (LWP 7149)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912551651792 (LWP 7136)]
0x00002aaaac8b4aa3 in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
(gdb) bt
#0 0x00002aaaac8b4aa3 in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
#1 0x00002aaaac8bb66d in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
#2 0x00002aaaac892f10 in cairo_image_surface_get_height ()
  from /usr/lib/libcairo.so.2
#3 0x00002aaaac898296 in cairo_surface_set_device_offset ()
  from /usr/lib/libcairo.so.2
#4 0x00002aaaac890732 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#5 0x00002aaaac8909e3 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#6 0x00002aaaac890ca7 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#7 0x00002aaaac88b00d in cairo_fill_preserve () from /usr/lib/libcairo.so.2
#8 0x00002aaaac88b029 in cairo_fill () from /usr/lib/libcairo.so.2
#9 0x00002aaaafae4cd0 in ubuntulooks_draw_progressbar_trough ()
  from /usr/lib/gtk-2.0/2.4.0/engines/libubuntulooks.so
#10 0x00002aaaafadf0c7 in ubuntulooks_rc_style_register_type ()
  from /usr/lib/gtk-2.0/2.4.0/engines/libubuntulooks.so
#11 0x00002aaaab71ad69 in gtk_progress_bar_new_with_adjustment ()
  from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00002aaaab71908f in gtk_progress_get_type ()
[...]

(I'll attach the entire trace).

I'll also attach a strace for: a segfaulting firefox; and a non-segfaulting firefox (where the only difference is that I've changed the gnome theme from Human to LegacyHuman).

Please let me know if there's anything else I should provide; this is one odd problem.

[R-vickers (r-vickers)]

I am seeing someting very similar on NCD and IBM X terminals. On SuSE 10.0
firefox 1.0.7 crashes with a segmentation fault as soon as you start it. I have
gtk2-2.8.3-4
cairo-1.0.0-7.2

Here is my traceback:

#0 0x00000000 in ?? ()
#1 0xb3658842 in _cairo_pixman_composite_tri_fan ()
   from /usr/lib/libcairo.so.2
#2 0xb365b906 in _cairo_pixman_composite_tri_fan ()
   from /usr/lib/libcairo.so.2
#3 0xb364bc69 in _cairo_pixman_region_intersect () from /usr/lib/libcairo.so.2
#4 0xb362d4a9 in cairo_image_surface_get_height () from /usr/lib/libcairo.so.2
#5 0xb3632d89 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#6 0xb362a573 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#7 0xb3629cb6 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#8 0xb362a97b in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#9 0xb362ab87 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#10 0xb362ac6a in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#11 0xb3624609 in cairo_stroke_preserve () from /usr/lib/libcairo.so.2
#12 0xb3624632 in cairo_stroke () from /usr/lib/libcairo.so.2
#13 0xb38e656e in gtk_style_apply_default_background ()
   from /opt/gnome/lib/libgtk-x11-2.0.so.0
#14 0xb38ed0c0 in gtk_paint_check () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#15 0x081c1aca in nsCharPtrHashKey::nsCharPtrHashKey ()
#16 0x081c0768 in nsCharPtrHashKey::nsCharPtrHashKey ()
#17 0x0823d4ff in nsCOMTypeInfo<nsITimerInternal>::GetIID ()
#18 0x0823df08 in nsCOMTypeInfo<nsITimerInternal>::GetIID ()
#19 0x08204c63 in nsIBidirectionalEnumerator::nsIBidirectionalEnumerator ()
#20 0x0825b55d in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#21 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#22 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#23 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#24 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#25 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#26 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#27 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#28 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#29 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#30 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#31 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#32 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#33 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#34 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#35 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#36 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#37 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#38 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#39 0x083e37bc in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#40 0x083e2e42 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#41 0x083e2624 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#42 0x08215570 in nsCOMPtr<nsIBidirectionalEnumerator>::nsCOMPtr ()
#43 0x08368f61 in nsCOMTypeInfo<nsICollection>::GetI...

[R-vickers (r-vickers)]

More news on this: a colleague reports that if you reconfigure the terminal to
use 16-bit colour instead of 8-bit then the problem goes away.

However this is an unhelpful solution for us: we switched the terminals to 8-bit
because firefox frequently crashed when visiting graphics-intensive sites.

Bob

[Carl Worth (cworth)]

I've updated the summary to note the limitation of this bug to the cased of X
servers running in 8-bit pseudocolor mode.

[Nate-byrnes (nate-byrnes)]

Regarding the recommendation to switch to 16-bit color... I cannot. The
tektronix is 8-bit only, as are many of the older X-Term products I have used
(NCD, IBM-Netstation). I really would love to go 16-bit if I could.

[Dominic Lachowicz (domlachowicz)]

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

[Hembrow (hembrow)]

I believe I'm seeing the same problem. I have a Tektronix XP117C X terminal,
which is 8 bit only, so changing the configuration to 16 bit or more is not
possible. I'm using GTK 2.8.6-0ubuntu2.1.

All sorts of old style X apps work fine if started on the display (i.e. xterm,
xeyes, xclock etc.), but gdm and such like don't work.

If this problem gets fixed, I'd be very pleased to hear about it.

David.

[R-vickers (r-vickers)]

I can imagine this bug could well be problematic for the developers because they
may not have access to old equipment. Is there anything those of us with 8-bit X
terminals can do to speed things up? It would cost this department about $25000
to replace all our 8-bit terminals, so I'm willing to invest some effort in
providing good debugging information, or testing out new versions of software.

[R-vickers (r-vickers)]

Created an attachment (id=4872)
Simple program to demonstrate bug

I downloaded a very simple Cairo demo from the Gnome Journal and this also
triggers the bug. The attachment includes:
(1) program source
(2) Makefile
(3) Debugging traceback (in cairo.log)

To compile the program type
  make clock3

[R-vickers (r-vickers)]

More information: this bug is a close relation of
https://bugs.freedesktop.org/show_bug.cgi?id=5846
and possibly the same. A colleague of mine built libcairo with the workround
suggested there and found that firefox and other applications now ran without
crashing on 8-bit terminals. However, there were some issues with text
displaying strangely, so there is still work to be done.

Bob

[Otaylor-redhat (otaylor-redhat)]

Retitling to hopefully make it clear that this isn't some problem
that needs diagnosis. If someone is interested in doing the work
(probably a week or so's worth of work), that could be discussed on
the cairo mailing list. Of course, making it stop crashing is easier
than making but of pretty limited value...

[Carl Worth (cworth)]

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

[Bohan-freedesktop (bohan-freedesktop)]

(In reply to comment #7)
> I can imagine this bug could well be problematic for the developers because they
> may not have access to old equipment.

couldn't we argue that cairo and gtk/gdk/pango developers could have at least
tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest?

[Carl Worth (cworth)]

(In reply to comment #12)
> couldn't we argue that cairo and gtk/gdk/pango developers could have at least
> tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest?

Certainly, getting access to an X server with an 8-bit pseudo-color visual is
not the problem. So, you're correct that an offer of hardware won't help get the
problem fixed.

The reason this situation exists is not due to some careless lack of testing.
For cairo at least, there was a conscious acknowledgment from the developers
that have been working on cairo so far that the 8-bit pseudo-color case is
uninteresting.

Obviously, (from the traffic here), there are users that are interested in this
case. So what falls to the users is finding a capable developer that is
motivated (or that could be made motivated) to fix this.

[Carl Worth (cworth)]

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

[R-vickers (r-vickers)]

(In reply to comment #13)
>
> The reason this situation exists is not due to some careless lack of testing.
> For cairo at least, there was a conscious acknowledgment from the developers
> that have been working on cairo so far that the 8-bit pseudo-color case is
> uninteresting.
>

Sadly there is a bit of a clash of expectations here. The Cairo developers are
busy working on what they find interesting, while in another part of the free
software ecosystem distributors like SuSE are including this partially
functional software in their products and selling it to the general public.

[Carl Worth (cworth)]

(In reply to comment #15)
>
> Sadly there is a bit of a clash of expectations here. The Cairo developers are
> busy working on what they find interesting, while in another part of the free
> software ecosystem distributors like SuSE are including this partially
> functional software in their products and selling it to the general public.

If a software distributor wants to sell you a product that doesn't meet your
needs, then don't buy it. There really are connections between what paying
customers care about and what developers will find interesting to work on.

[Eric-faurot (eric-faurot)]

(In reply to comment #16)

(well, not really)

Hi,

I add this note to the tracker (after a suggestion by Bob) to let people not
following the cairo devel list know that I have written a patch for that isue:

http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c

I have personally tested it on OpenBSD/macppc in various combinations of
ati/wscons drivers and ssh-X/-Y. I also have postive feedback from Bob
(thank you). If you find this useful let me know, also read
http://ekyo.nerim.net/software/index.html

Eric.

[Tom-nelson (tom-nelson)]

For what it is worth I've had to workaround cairo color issues as a developer
of a comercial product built on top of wxwidgets, by using gtk+2.6.10 the last
gtk version before the adoption of cairo. My research indicates that QT on top
of cairo gtk also had similar issues. To our surprise our first comercial
customers wanted to use our product on X-Win32 and Solaris and encounted some
of these issues.

I very much look forward to the incorporation of this bug fix into a future
cairo release and suggest that perhaps bugs 5212, 5681, and 5846 may be related.

I have a news group corespondence on gmane.comp.lib.wxwindows.general (search
for "Apparent RGB") that may be of interest. Thanks -- Tom

[Woods-logins-for-bug-reporting-are-stupid-and-counter-productive (woods-logins-for-bug-reporting-are-stupid-and-counter-productive)]

FYI this bug has now wasted a week's worth of my time in trying to upgrade
packages that previously worked A-OK in my environments on NetBSD (i386, alpha,
and sparc). Confusion with weird pthread problems on SMP machines, along with
the fact that this bugzilla database doesn't seem to be indexed very well by
google didn't help of course. :-)

It's now a complete show-stopper for me for any and all applications needing
gtk2+.

gtk-demo is a great canonical example program that crashes on all platforms I've
tested.

Note that prior to these upgrades all the applications I'm attempting to upgrade
worked OK even on monochrome displays (albiet with some invisible features
whenever too many colours are used in proximity with each other by the
application).

Note of course that the bug is still present in 1.0.4 as well.

I'll be testing out the patch suggested in a recent comment.

[Eric-faurot (eric-faurot)]

Created an attachment (id=5796)
fix for the 8bit issue + 16 bit.

Hi all,

There was a bug in my previous fix. Color channels were mixed up
on some archs. This should be much better now. It should also be faster.
I have also added a workaround for 16bits displays with the RENDER extension
disabled.

Also updated there:
http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c

Eric.

[Freedesktop (freedesktop)]

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

[Brian-cameron-oracle (brian-cameron-oracle)]

This patch seems to work against cairo 1.0, not 1.2. Is there an updated patch
for the new release of cairo, or can this patch be integrated into cairo?

[Eric-faurot (eric-faurot)]

(In reply to comment #22)
> This patch seems to work against cairo 1.0, not 1.2. Is there an updated patch
> for the new release of cairo, or can this patch be integrated into cairo?

Hi,

I have just ported my patch to cairo-1.2.0.
http://ekyo.nerim.net/software/patch-1.2.0-src_cairo-xlib-surface_c
Eric.

[Carl Worth (cworth)]

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

[Dan McMahill (dmcmahill)]

any chance of a patch against 1.2.4? I just checked 1.2.4 and it still has this
problem. Unfortunately the 1.2.0 patch didn't apply cleanly and I don't
understand it enough to work it into the 1.2.4 code. Surely this must affect
quite a number of users. For now I will just not move past gtk-2.6.

Just to append to this, I'm using a Sun ultra/10 with the default graphics card.
 In this case that means I'm running 8-bit psuedocolor. Thats the best you get
with 1280 x 1024. To go to something like 24-bit color you have to drop down to
1024 x 768 which is just not enough. Granted this is not a cutting edge machine
but I'll bet there are a lot of them deployed. I'd be happy to test out any
patches.

[Dan McMahill (dmcmahill)]

Created an attachment (id=6762)
update of Eric Faurot's patch for 1.2.4

I managed to get Eric's patch for 1.2.0 to apply to 1.2.4 with some manual
help. I can't claim to understand his changes (or any of cairo's internals),
but with this patch I can display gtk apps on my sun ultra/10 again.

Are there any plans of integrating this into the main sources?

Thanks
-Dan

[Schwarzb (schwarzb)]

Created an attachment (id=6819)
Fix of patch #6762 for true color

The patch #6762 works indeed for 8-bit Pseudo-Color with SUN-X-Servers, but
breaks 24-Bit-True Color Visual compatibility there. The new attchment contains
a patch derived from #6762 wich works also with True Color. Additionally, code
parts aparrantly obsoleted (?) by pango-1.2 (WORKAROUND_8BIT_GRAYLEVEL,
WORKAROUND_R5G6B5) have been removed. By now it's tested only briefly with
SUN-X-Server on 8-bit Pseudo-Color and 24-Bit-True Color Visuals.

[Daniel Allen (dada-da)]

On a batch of machines I just dist-upgraded from Breezy to Dapper, Firefox
(and gimp) will segfault when they are run from gnome via XDMCP
(thin-client).

It doesn't segfault from KDE via XDMCP, and it doesn't segfault from
gnome from non-XDMCP X (monitor plugged directly into server). Further, it doesn't segfault when the gnome theme is changed from 'Human' to 'LegacyHuman'.

I installed 'firefox-dbg' and run firefox -g, with the following output:

---
drallen@host:~$ firefox
Segmentation fault
drallen@host:~$ firefox -g
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
library"/lib/libthread_db.so.1".

(gdb) r
Starting program: /usr/lib/firefox/firefox-bin -a firefox
[Thread debugging using libthread_db enabled]
[New Thread 46912551651792 (LWP 7136)]
[New Thread 1082132832 (LWP 7147)]
[New Thread 1090525536 (LWP 7148)]
[New Thread 1098918240 (LWP 7149)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912551651792 (LWP 7136)]
0x00002aaaac8b4aa3 in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
(gdb) bt
#0 0x00002aaaac8b4aa3 in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
#1 0x00002aaaac8bb66d in _cairo_pixman_composite_tri_fan ()
  from /usr/lib/libcairo.so.2
#2 0x00002aaaac892f10 in cairo_image_surface_get_height ()
  from /usr/lib/libcairo.so.2
#3 0x00002aaaac898296 in cairo_surface_set_device_offset ()
  from /usr/lib/libcairo.so.2
#4 0x00002aaaac890732 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#5 0x00002aaaac8909e3 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#6 0x00002aaaac890ca7 in cairo_font_options_get_hint_metrics ()
  from /usr/lib/libcairo.so.2
#7 0x00002aaaac88b00d in cairo_fill_preserve () from /usr/lib/libcairo.so.2
#8 0x00002aaaac88b029 in cairo_fill () from /usr/lib/libcairo.so.2
#9 0x00002aaaafae4cd0 in ubuntulooks_draw_progressbar_trough ()
  from /usr/lib/gtk-2.0/2.4.0/engines/libubuntulooks.so
#10 0x00002aaaafadf0c7 in ubuntulooks_rc_style_register_type ()
  from /usr/lib/gtk-2.0/2.4.0/engines/libubuntulooks.so
#11 0x00002aaaab71ad69 in gtk_progress_bar_new_with_adjustment ()
  from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00002aaaab71908f in gtk_progress_get_type ()
[...]

(I'll attach the entire trace).

I'll also attach a strace for: a segfaulting firefox; and a non-segfaulting firefox (where the only difference is that I've changed the gnome theme from Human to LegacyHuman).

Please let me know if there's anything else I should provide; this is one odd problem.

[Daniel Allen (dada-da)]

only difference: changed user theme from 'Human' to 'LegacyHuman'

[Sebastien Bacher (seb128)]

Looks like a cairo bug according to the backtrace which is similar to https://bugs.freedesktop.org/show_bug.cgi?id=4945 upstream. Reassigning. Do you use a 8 bits graphical server?

[Walter Tautz (wtautz)]

Just a note. This is on amd64 architecture. It's not clear whether this would
be a problem on another arch.

[Daniel Allen (dada-da)]

The thin client says it's 16-bits, and xpdyinfo seems to concur:

name of display: redacted:1.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40300000
XFree86 version: 4.3.0
maximum request size: 4194300 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
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 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
keycode range: minimum 8, maximum 255
focus: window 0x160001f, revert to Parent
number of extensions: 18
    BIG-REQUESTS
    DPMS
    Extended-Visual-Information
    FontCache
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RENDER
    SECURITY
    SHAPE
    TOG-CUP
    X-Resource
    XC-MISC
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XInputExtension
    XVideo
default screen number: 0
number of screens: 1

screen #0:
  dimensions: 1280x1024 pixels (433x347 millimeters)
  resolution: 75x75 dots per inch
  depths (7): 16, 1, 4, 8, 15, 24, 32
  root window id: 0x36
  depth of root window: 16 planes
  number of colormaps: minimum 1, maximum 1
  default colormap: 0x20
  default number of colormap cells: 64
  preallocated pixels: black 0, white 65535
  options: backing-store YES, save-unders YES
  largest cursor: 64x64
  current input event mask: 0xfa2033
    KeyPressMask KeyReleaseMask EnterWindowMask
    LeaveWindowMask ButtonMotionMask StructureNotifyMask
    SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask
    PropertyChangeMask ColormapChangeMask
  number of visuals: 2
  default visual id: 0x21
  visual:
    visual id: 0x21
    class: TrueColor
    depth: 16 planes
    available colormap entries: 64 per subfield
    red, green, blue masks: 0xf800, 0x7e0, 0x1f
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x22
    class: DirectColor
    depth: 16 planes
    available colormap entries: 64 per subfield
    red, green, blue masks: 0xf800, 0x7e0, 0x1f
    significant bits in color specification: 8 bits

[Daniel Allen (dada-da)]

Also confirmed on i386 arch (6.06).

[Carl Worth (cworth)]

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

[Dan McMahill (dmcmahill)]

This is just a note that attachement #6819 seems to work for me. I'm using an
8-bit psuedocolor display (Sun ultra/10, solaris-2.9, Xsun).

What are the chances of this patch making its way back to the main sources?

Thanks
-Dan

[Chris Palmer (cwrefp)]

I would prefer a patch that has all the workarounds (WORKAROUND_8BIT_GRAYLEVEL and
WORKAROUND_R5G6B5 included) and doesn't break 24-Bit-True Color Visual compatibility. I think the workarounds are useful (or could potentially be useful) for more than just pango.

[Pesco (pesco-auto-created)]

I'm experiencing the same "crash-all-gtk-apps" symptom on my remote setup. Of
note is that the display in question is 16bit, the problem also appears at
24bit. My segfault, when running 'gtk-demo' happens in
_cairo_xlib_surface_show_glyphs:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1218046288 (LWP 16941)]
    0xb78f8039 in _cairo_xlib_surface_show_glyphs () from /usr/lib/libcairo.so.2

The client machine is Linux/Intel whereas the X server is running on Linux/
PowerPC.

[Pesco (pesco-auto-created)]

(In reply to comment #31)
Right, these are Cairo 1.2.4 and GTK 2.10.6...

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Drahflow (drahflow)]

Seems like I have a similar problem, only now cairo spills some error messages about not supporting 8-bit visuals.

[Florian-heigl (florian-heigl)]

Hi,

I also hit this behaviour in a RHEL5 + Sun Secure Global Desktop scenario.

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

[root@localhost ~]# rpm -aq | grep -i pango
pango-1.13.4-2
pycairo-1.2.0-1.1
cairo-1.2.0-2

I read through all the related info here now, and I think someone from the dev's
should test the patches submitted here AND drop a line to Redhat. They might
want to patch up their version.

FYI, i think I can switch my colordepth setting somewhere, but when I hit the
error I ended up getting about 200 windows created till I could kill it - *not*
pleasant :))

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Eth0-o2 (eth0-o2)]

On OpenBSD 4.0-current (Wed Dec 6 03:34:00 MST 2006), X.org 6.9.0 depth 16bit
with cairo-1.2.6 gtk+2-2.10.6 pango-1.14.7 and patch id=6819 form this bug
id=4945 nautilus 2.16.3 crashes like:

Breakpoint 1, cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000,
    bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
    at cairo-xlib-surface.c:2154
2154 return _cairo_xlib_surface_create_internal (dpy, bitmap, screen,
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000,
    drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0,
    width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
2065 if (xrender_format == NULL &&
(gdb) bt
#0 0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000,
    drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0,
    width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
#1 0x0919eb15 in cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000,
    bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
    at cairo-xlib-surface.c:2154
#2 0x0adcd87a in gdk_x11_ref_cairo_surface (drawable=0x885f9640)
    at gdkdrawable-x11.c:1474
#3 0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x885f9640)
    at gdkdraw.c:1263
#4 0x0ada9110 in gdk_pixmap_ref_cairo_surface (drawable=0x808914d0)
    at gdkpixmap.c:515
#5 0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x808914d0)
    at gdkdraw.c:1263
#6 0x0ad98a69 in gdk_cairo_create (drawable=0x808914d0) at gdkcairo.c:45
#7 0x0ada350b in get_cairo_context (gdk_renderer=0x884ad010,
    part=PANGO_RENDER_PART_FOREGROUND) at gdkpango.c:160
#8 0x0ada36c4 in gdk_pango_renderer_draw_glyphs (renderer=0x884ad010,
    font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416) at gdkpango.c:230
#9 0x021065ef in pango_renderer_draw_glyphs (renderer=0x884ad010,
    font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416)
    at pango-renderer.c:598
#10 0x021063e8 in pango_renderer_draw_layout_line (renderer=0x884ad010,
    line=0x80891368, x=3584, y=60416) at pango-renderer.c:529
#11 0x02105c00 in pango_renderer_draw_layout (renderer=0x884ad010,
    layout=0x89312678, x=1024, y=50176) at pango-renderer.c:183
#12 0x0ada51d3 in gdk_draw_layout_with_colors (drawable=0x808914d0,
    gc=0x81907dd0, x=1, y=49, layout=0x89312678, foreground=0x0,
    background=0x0) at gdkpango.c:1029
#13 0x0ada54b3 in gdk_draw_layout (drawable=0x808914d0, gc=0x81907dd0, x=1,
    y=49, layout=0x89312678) at gdkpango.c:1091
#14 0x1c0cd999 in nautilus_undo_transaction_unregister_object ()
#15 0x1c0cc827 in nautilus_undo_transaction_unregister_object ()
#16 0x1c0cb793 in nautilus_undo_transaction_unregister_object ()
#17 0x1c0b1162 in nautilus_icon_container_request_update_all ()
#18 0x061b6dfe in g_cclosure_marshal_VOID__OBJECT ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#19 0x061a5f6e in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#20 0x061b6081 in g_signal_emit_by_name ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#21 0x061b521e in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#22 0x0...

[Freedesktop (freedesktop)]

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

[Sebastien Bacher (seb128)]

Marking confirmed, the bug is known upstream

[Freedesktop (freedesktop)]

Patch used in Sun's JDS: http://cvs.opensolaris.org/source/xref/jds/spec-files/trunk/patches/cairo-02-8bit-fix.diff

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Freedesktop (freedesktop)]

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

[Dan McMahill (dmcmahill)]

By my count there have been 16 other bug reports marked as duplicates of this one. Several patches have been offered and unless I missed it, there has been no negative feedback about these patches which has not been addressed.

Is there any chance at all of these patches ever making their way back into the main source tree? Or is it always going to be the case that users will have to maintain patches if they care about users that may have older displays? Note that some users may be running on high end computers but still may have older displays and are thus crippled with this.

I'm sure many of us would like to hear some official feedback especially if it is a step towards getting this fixed in the official sources. It seems there is no shortage of users to test patches although as someone pointed out quite a while back, VNC can give you access to displays with different color depths.

I hate to complain too much because I'm someone who also contributes quite a bit to various open source projects I realize there isn't always time to look at all the bug reports and patch submissions, but at the same time, cairo is really critical to many many apps and it seems that the patches proposed here are seeing quite a bit of real life use and day to day testing.

[Chris Palmer (cwrefp)]

Perhaps it is because all the patches I've seen would need some
tidying up before they'd be suitable - `patch' is very much the
right word for the code given within them. They work, but
you wouldn't want cairo to be comprised entirely of these patches.
I would expect that if one of the patches was polished up a bit, it might
have a better chance of being merged...

[Carl Worth (cworth)]

(In reply to comment #47)
> By my count there have been 16 other bug reports marked as duplicates of this
> one.

Yes, and the duplicates alone are annoying enough that I'd definitely like to see this bug (and other similar ones) go away for good. We've even added this to the RAODMAP for somewhere along the 1.4.x or 1.6. See:

    http://cairographics.org/ROADMAP

> Several patches have been offered and unless I missed it, there has been
> no negative feedback about these patches which has not been addressed.

That's primarily because I've never even seen a patch that the author has suggested was clean or complete.

And I believe the most recent discussion has happened on the cairo mailing list, not here in bugzilla, (and the whole split-conversation thing is something that I dislike about bugzilla very much).

Here's a pointer to what I think is the most recent post on the mailing list on the topic:

http://lists.freedesktop.org/archives/cairo/2007-February/009731.html

I'd be happy to have help with this, (including success reports),

-Carl

[Dan McMahill (dmcmahill)]

thanks. I'll direct further questions to the mailing list. FWIW, here is a link to the patch currently used by NetBSD pkgsrc: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/graphics/cairo/patches/patch-ae

It seems to work alright for me with a Sun ultra/10 display (8 bit psuedo color) and we have not been hearing complaints from other users with more modern displays. Since cairo affects much of gnome as well as firefox/thunderbird/etc it is reasonably safe to assume that the attached patch has received a fair amount of road testing.

[Freedesktop (freedesktop)]

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

[Brian-cameron-oracle (brian-cameron-oracle)]

Created an attachment (id=9844)
updated patch for cairo 1.4.6

I noticed that the latest version of this patch is for cairo 1.4.2 and apply against cairo 1.4.6. The code is pretty much the same, though the structures have now moved into cairo-xlib-surface-private.h.

I notice when I log into my session passing "-depth 8" to the Xorg Xserver, so I am running in 8bit mode that there are some problems:

- sometimes the background image doesn't look right. Depending on the
  background image used, it looks like it isn't being scaled cleanly or it
  sometimes has horizontal black lines running through the image.
- I also notice that gnome-screenshot seems to take really messed up pictures
  of the desktop.

So I'm not sure 8bit mode works perfectly even with this patch applied, though those bugs may not be related to cairo. I'm not sure. I see the exact same problems running with the earlier version of the patch with cairo 1.4.0, so I do not think these problems are introduced by my update of the patch.

I haven't filed bugs against these two issues yet since this 8bit logic isn't yet integrated into cairo. I just mention I am seeing these problems so the cairo developers can look into this and see if they might understand what the problems may be. If these aren't cairo problems, we probably should file bugs against control-center Desktop Background capplet and gnome-screenshot once this patch goes upstream.

[Carl Worth (cworth)]

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

[Carl Worth (cworth)]

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

[Carl Worth (cworth)]

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

[Kalle Vahlman (zuh)]

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

[idefix (chris-wang)]

It seems that cairo not only doesn't support 8bit pseudocolor but also Truecolor, remember there is still a case that the 8bit color represent as truecolor with 2bit blue, 3bit Green and 3bit Red, this kind of color system still been used in some case.

[idefix (chris-wang)]

Created an attachment (id=11071)
Revise the patch to support 8bit truecolor also

[Carl Worth (cworth)]

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

[Carl Worth (cworth)]

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

[Carl Worth (cworth)]

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

[Carl Worth (cworth)]

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

[Thayes77 (thayes77)]

So I'm trying to figure out how to apply this patch. I will say I know almost nothing about Linux, but I am a physics/astrophysics major, and most of our programs are written in Linux. It's been a helluva ride getting my program to run in Linux period, and now part of it requires running in 8 bit. But every time I try to start an 8-bit window, I get the Cairo error. If this patch can let me run my 8-bit, it will be a life saver. can anybody tell me what I do with this patch to make it work?

[Carl Worth (cworth)]

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

[Marek-rouchal (marek-rouchal)]

I stumbled across a similar problem: Firefox wouldn't start on a 256-color Citrix Metaframe (aka ICA) display (commercial software to display X on a Windows PC). So I took cairo-1.4.12, applied the most recent of the attached patches, compiled my own libcairo, and started firefox 2.0.0.6 with LD_LIBRARY_PATH set to the new libcairo, which resulted in this error message:

Error: Cairo 1.4.12 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
firefox-bin: cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.

I tried changing line 173 of src/cairo-image-surface.c to:
    case 8:
       if ((am == 0xff || am == 0x0) &&

But that did not help - firefox then crashes with a segfault. Could be that the version jump of libcairo.so.2.9.2 to libcairo.so.2.11.6 was too high, and I'd have to recompile all GTK/firefox, which I cannot afford. I will try patching the older release of cairo (1.2.4), and let you know...

[Marek-rouchal (marek-rouchal)]

(In reply to comment #65)
> I will try patching
> the older release of cairo (1.2.4), and let you know...

I used Dan's patch (https://bugs.freedesktop.org/attachment.cgi?id=6762) on cairo-1.2.4, forced firefox to use the patched libcairo.so via LD_LIBRARY_PATH and now firefox starts up happily in 8bit/256color mode on a remote connection (X Server: Citrix ICA 256 color mode). I cannot test later versions of cairo unfortunately, but at least you have this proof that the patch addresses the "depth 8" mode. Keep up the good work!
-Marek

[Freedesktop (freedesktop)]

Thanks Marek. Can you attach a screenshot?! I'm curious how it looks.

[Marek-rouchal (marek-rouchal)]

Created an attachment (id=13517)
screenshot of firefox on 256 color (depth 8) display

[Fboiteux (fboiteux)]

Hello,

  I can't use libcairo and all GTK applications of a Debian Etch (cairo 1.2.4) on my X11 NCD terminal (8bit colors) since a long time. I've tried to use patch #6762, and with it, applications launch but giving a lot of messages like :

No workaround for this pixel format: Visual: class=TrueColor, bpRGB=8, CM=8, r=7, g=38, b=c0
...
And no text appear !

  I've also tried patch #6819, but applications fail :
.../libcairo-1.2.4/src/cairo-image-surface.c:155: _cairo_format_from_pixman_format: l'assertion « NOT_REACHED » a échoué.
Error: Cairo does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red mask: 0x00000007
        Green mask: 0x00000038
        Blue mask: 0x000000c0
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo

I'm not as lucky as Marek, and always stuck on old Debian Sarge from 2005 :-(

[Ashish (ashishyadav26)]

Hi,

I applied patch 11071 on cairo 1.4.10 on AIX 52. Build Firefox with the 1.4.10 devel RPM, however Firefox still crashed when started in 8 bit color mode.

Following was the error

Error: Cairo 1.4.10 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
The assert subroutine failed: NOT_REACHED, file cairo-image-surface.c, line 199
obj-opt/dist/bin/run-mozilla.sh[36]: 217132 IOT/Abort trap(coredump)

[Ashish (ashishyadav26)]

Created an attachment (id=14169)
Patch which worked on AIX 52

I tried to play around with the patch 11071, and this is what worked finally ( was able to run Firefox) in both Pseudo color and True color.

Looking for assistance in finding a suitable fix.

[Freedesktop (freedesktop)]

(In reply to comment #71)
> Created an attachment (id=14169) [details]
> Patch which worked on AIX 52
>
> I tried to play around with the patch 11071, and this is what worked finally (
> was able to run Firefox) in both Pseudo color and True color.
>
> Looking for assistance in finding a suitable fix.

Screenshots? Does this fix have the same artifacts as the last screenshot posted?

[Stefan Schmidt (zaphodb)]

i have a monochrome XTerminal NCD 16e, same blues:

collin:~> firefox
Error: Cairo 1.4.14 does not yet support the requested image format:
       Depth: 1
       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
firefox-bin: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
Abort

;)

 Zap

[Adrian Johnson (ajohnson-redneon)]

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

[Carl Worth (cworth)]

This bug is now fixed in the cairo 1.5.14 snapshot and the fix will appear in the imminent 1.6.0 cairo release.

Please test and let me know how things go.

-Carl

[Pedro Villavicencio (pedro)]

fixed upstream, thanks for reporting.

[Sebastien Bacher (seb128)]

the new version has been uploaded to hardy

[Fboiteux (fboiteux)]

  Hello,

I've tested new 1.6.4 Cairo on a Debian Etch system (by recompiling the 1.6.4-1 Debian Sid package), and tested it on my X11 terminal : it works, but I still have a problem : all texts are painted with ugly colors (something like pink on purple (see attachment), and it's unusable. As i know there is different kinds of 8bits display, and that I tested this new Cairo version through Debian packaging, I wonder if the problem comes from Cairo, Debian packaging, GTK2 or something else. Is there something I can do to help to fix it ?

[Fboiteux (fboiteux)]

Created an attachment (id=16702)
Capture of part of my screen, with 'gkrellm' from new Cairo on the top and from an old no-Cairo version on the bottom

[Marek-rouchal (marek-rouchal)]

Created an attachment (id=22849)
screen capture of Firefox 2.0.0.17 with cairo-1.8.6 on 256 color X11 on Solaris 10 x86

I confirm that cairo-1.8.6 fixes this problem; rendering on 256-color X11 works OK now. Thanks to the developers, good job!