registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #15397
[Bug 61303] Re: gtk apps segfault on gnome 'Human' theme, only from XDMCP
Launchpad has imported 79 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=4945.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2005-11-02T04:42:21+00:00 Nate-byrnes wrote:
When trying to run any gtk app (so it seems, due to the pangocairo, cairo
dependency) on my Tektronix Xterm, the app crashes as the window attempts to
map. This does not happen on Linux-Linux remote X11 (DISPLAY=host:0.0), just
Linux-Xterm (DISPLAY=xterm:0.0). Below is the stacktrace of running gcalctool,
but every other GTK app I run dies the same way. I first discovered this after
upgrading to dropline-gnome 2.12 and tried to login to the xterm via GDM.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226455360 (LWP 17605)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xb75b435d in fbFetch (pict=0x81faaf8, x=0, y=0, width=10, buffer=0xbfd4fc08)
at fbcompose.c:2673
#2 0xb75b65b3 in fbCompositeRect (data=0xbfd4fbc0, scanline_buffer=0xbfd4fbe0)
at fbcompose.c:3565
#3 0xb75b6ba6 in pixman_compositeGeneral (op=PIXMAN_OPERATOR_OVER,
pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0,
yMask=0, xDst=0, yDst=0, width=10, height=64480) at fbcompose.c:3677
#4 0xb75a7022 in *_cairo_pixman_composite (op=PIXMAN_OPERATOR_OVER,
pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0,
yMask=0, xDst=0, yDst=0, width=10, height=10) at fbpict.c:1825
#5 0xb758c0d3 in _cairo_image_surface_composite (operator=CAIRO_OPERATOR_OVER,
src_pattern=0xbfd56210, mask_pattern=0xbfd55eb0, abstract_dst=0x81fab70,
src_x=10, src_y=9, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=10, height=10)
at cairo-image-surface.c:605
#6 0xb75919ef in _fallback_composite (operator=CAIRO_OPERATOR_OVER,
src=0xbfd56210, mask=0xbfd55eb0, dst=0x81f9c48, src_x=10, src_y=9, mask_x=0,
mask_y=0, dst_x=0, dst_y=0, width=10, height=10) at cairo-surface.c:800
#7 0xb759b091 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x814ecf0,
operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48,
source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10,
glyphs=0x81f9af0, num_glyphs=1) at cairo-ft-font.c:2047
#8 0xb75872dc in _cairo_scaled_font_show_glyphs (scaled_font=0x814ecf0,
operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48,
source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10,
glyphs=0x81f9af0, num_glyphs=1) at cairo-font.c:940
#9 0xb758a8f2 in _cairo_gstate_show_glyphs_draw_func (closure=0xbfd561f0,
operator=CAIRO_OPERATOR_OVER, src=0xbfd56210, dst=0x81f9c48, dst_x=0,
dst_y=0, extents=0xbfd561e8) at cairo-gstate.c:2053
#10 0xb75893cc in _cairo_gstate_clip_and_composite (clip=0x81fa694,
operator=CAIRO_OPERATOR_OVER, src=0xbfd56210,
draw_func=0xb758a830 <_cairo_gstate_show_glyphs_draw_func>,
draw_closure=0xbfd561f0, dst=0x81f9c48, extents=0xbfd561e8)
at cairo-gstate.c:1094
#11 0xb758ab0e in _cairo_gstate_show_glyphs (gstate=0x81fa610,
glyphs=0xbfd562f0, num_glyphs=1) at cairo-gstate.c:2131
#12 0xb75840ec in cairo_show_glyphs (cr=0x81f9ab8, glyphs=0x0,
num_glyphs=136292848) at cairo.c:2158
#13 0xb75bf2bd in pango_cairo_renderer_draw_glyphs (renderer=0x81fa450,
font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pangocairo-render.c:110
#14 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81fa450,
font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pango-renderer.c:597
#15 0xb75bf7f4 in pango_cairo_show_glyph_string (cr=0x81f9ab8, font=0x8146b70,
glyphs=0x81606e8) at pangocairo-render.c:314
#16 0xb7ae5df9 in gdk_pango_context_get_for_screen ()
from /usr/lib/libgdk-x11-2.0.so.0
#17 0x081f9ab8 in ?? ()
#18 0x08146b70 in ?? ()
#19 0x081606e8 in ?? ()
#20 0x00000000 in ?? ()
#21 0x40330000 in ?? ()
#22 0xb74720d2 in ?? () from /usr/lib/libpango-1.0.so.0
#23 0xbfd56710 in ?? ()
#24 0xbfd56700 in ?? ()
#25 0xb746ef38 in ?? () from /usr/lib/libpango-1.0.so.0
#26 0xb757ba58 in ?? ()
#27 0x081672f8 in ?? ()
#28 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#29 0x00000000 in ?? ()
#30 0x081f9e70 in ?? ()
#31 0xbfd56718 in ?? ()
#32 0x081f9ab8 in ?? ()
#33 0x00000014 in ?? ()
#34 0x00000003 in ?? ()
#35 0x00000000 in ?? ()
#36 0xb7a66794 in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0
#37 0xb7ac9f00 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#38 0xb7b533a8 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#39 0xb7f5bfd8 in ?? () from /lib/ld-linux.so.2
#40 0x00000001 in ?? ()
#41 0xb757ba58 in ?? ()
#42 0x00000001 in ?? ()
#43 0x08163638 in ?? ()
#44 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#45 0x081f9e70 in ?? ()
#46 0x081f9e70 in ?? ()
#47 0xbfd56738 in ?? ()
#48 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#49 0x081f9e70 in ?? ()
#50 0x081f9e70 in ?? ()
#51 0xbfd56758 in ?? ()
#52 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81606e8,
font=0x8128b68, glyphs=0x811ff68, x=135520048, y=0) at pango-renderer.c:597
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/0
------------------------------------------------------------------------
On 2005-11-04T06:29:28+00:00 R-vickers wrote:
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>::GetIID ()
#44 0x0836b89e in nsCOMTypeInfo<nsICollection>::GetIID ()
#45 0x0836eedf in nsCOMTypeInfo<nsICollection>::GetIID ()
#46 0x0836f8b5 in nsCOMTypeInfo<nsICollection>::GetIID ()
#47 0x0836fc5f in nsCOMTypeInfo<nsICollection>::GetIID ()
#48 0x08369002 in nsCOMTypeInfo<nsICollection>::GetIID ()
#49 0x081fe29b in nsCOMPtr<nsISupports>::nsCOMPtr ()
#50 0x081fa4a8 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#51 0x081fa4e3 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#52 0xb388ae60 in gtk_marshal_VOID__UINT_STRING ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#53 0xb35ebd19 in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0
#54 0xb35fb816 in g_signal_stop_emission ()
from /opt/gnome/lib/libgobject-2.0.so.0
#55 0xb35fcbee in g_signal_emit_valist ()
from /opt/gnome/lib/libgobject-2.0.so.0
#56 0xb35fd1f5 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0
#57 0xb397d3b4 in gtk_widget_activate ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#58 0xb3889845 in gtk_main_do_event () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#59 0xb37073fd in gdk_window_clear_area_e ()
from /opt/gnome/lib/libgdk-x11-2.0.so.0
#60 0xb37074df in gdk_window_process_all_updates ()
from /opt/gnome/lib/libgdk-x11-2.0.so.0
#61 0xb3707565 in gdk_window_process_all_updates ()
from /opt/gnome/lib/libgdk-x11-2.0.so.0
#62 0xb3581941 in g_child_watch_add () from /opt/gnome/lib/libglib-2.0.so.0
#63 0xb357f35c in g_main_context_dispatch ()
from /opt/gnome/lib/libglib-2.0.so.0
#64 0xb35827cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0
#65 0xb3582ce7 in g_main_context_iteration ()
from /opt/gnome/lib/libglib-2.0.so.0
#66 0x081fdae0 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#67 0x0857d697 in nsCOMPtr<nsIEventQueue>::nsCOMPtr ()
#68 0x084d2411 in nsCOMTypeInfo<nsIProcess>::GetIID ()
#69 0x084d114b in nsCOMTypeInfo<nsIProcess>::GetIID ()
#70 0x086edd56 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID ()
#71 0x086ef526 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID ()
#72 0x080810db in ?? ()
#73 0x00000001 in ?? ()
#74 0xbfd446a4 in ?? ()
#75 0x086f88d0 in _IO_stdin_used ()
#76 0xbfd44678 in ?? ()
#77 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6
#78 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6
#79 0x08081031 in ?? ()
Hope this can be fixed, it is a complete showstopper for SuSE 10 at this
site.
Bob
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/1
------------------------------------------------------------------------
On 2005-11-04T08:11:01+00:00 R-vickers wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/2
------------------------------------------------------------------------
On 2005-11-04T09:11:36+00:00 Carl Worth wrote:
I've updated the summary to note the limitation of this bug to the cased of X
servers running in 8-bit pseudocolor mode.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/3
------------------------------------------------------------------------
On 2005-11-05T07:50:31+00:00 Nate-byrnes wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/4
------------------------------------------------------------------------
On 2006-01-06T14:34:46+00:00 Dominic Lachowicz wrote:
*** Bug 5196 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/5
------------------------------------------------------------------------
On 2006-02-02T06:58:01+00:00 Hembrow wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/6
------------------------------------------------------------------------
On 2006-03-10T01:03:30+00:00 R-vickers wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/7
------------------------------------------------------------------------
On 2006-03-10T02:35:02+00:00 R-vickers wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/8
------------------------------------------------------------------------
On 2006-03-15T03:02:33+00:00 R-vickers wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/9
------------------------------------------------------------------------
On 2006-03-15T03:10:17+00:00 Otaylor-redhat wrote:
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...
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/10
------------------------------------------------------------------------
On 2006-03-25T09:03:06+00:00 Carl Worth wrote:
*** Bug 6379 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/11
------------------------------------------------------------------------
On 2006-04-07T04:00:58+00:00 Bohan-freedesktop wrote:
(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?
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/12
------------------------------------------------------------------------
On 2006-04-07T04:28:00+00:00 Carl Worth wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/13
------------------------------------------------------------------------
On 2006-04-19T17:07:26+00:00 Carl Worth wrote:
*** Bug 5205 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/14
------------------------------------------------------------------------
On 2006-04-21T23:23:05+00:00 R-vickers wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/15
------------------------------------------------------------------------
On 2006-04-22T02:44:28+00:00 Carl Worth wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/16
------------------------------------------------------------------------
On 2006-04-27T00:25:31+00:00 Eric-faurot wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/17
------------------------------------------------------------------------
On 2006-05-03T04:16:41+00:00 Tom-nelson wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/18
------------------------------------------------------------------------
On 2006-05-12T03:45:52+00:00 Woods-logins-for-bug-reporting-are-stupid-and-counter-productive wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/19
------------------------------------------------------------------------
On 2006-06-03T09:58:27+00:00 Eric-faurot wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/20
------------------------------------------------------------------------
On 2006-06-13T22:57:35+00:00 Freedesktop wrote:
*** Bug 4505 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/21
------------------------------------------------------------------------
On 2006-07-10T10:38:22+00:00 Brian-cameron-oracle wrote:
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?
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/22
------------------------------------------------------------------------
On 2006-07-21T09:10:42+00:00 Eric-faurot wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/23
------------------------------------------------------------------------
On 2006-08-30T10:56:24+00:00 Carl Worth wrote:
*** Bug 8073 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/24
------------------------------------------------------------------------
On 2006-08-30T11:52:49+00:00 Dan McMahill wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/25
------------------------------------------------------------------------
On 2006-08-31T04:58:57+00:00 Dan McMahill wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/26
------------------------------------------------------------------------
On 2006-09-05T02:31:48+00:00 Schwarzb wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/27
------------------------------------------------------------------------
On 2006-09-25T09:53:28+00:00 Carl Worth wrote:
*** Bug 8416 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/36
------------------------------------------------------------------------
On 2006-09-30T03:28:13+00:00 Dan McMahill wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/37
------------------------------------------------------------------------
On 2006-09-30T15:21:17+00:00 Cpalmer-maths wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/38
------------------------------------------------------------------------
On 2006-10-22T13:58:03+00:00 Pesco wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/39
------------------------------------------------------------------------
On 2006-10-22T14:03:25+00:00 Pesco wrote:
(In reply to comment #31)
Right, these are Cairo 1.2.4 and GTK 2.10.6...
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/40
------------------------------------------------------------------------
On 2006-10-25T14:24:50+00:00 Freedesktop wrote:
*** Bug 8382 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/41
------------------------------------------------------------------------
On 2006-10-25T14:25:04+00:00 Freedesktop wrote:
*** Bug 8530 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/42
------------------------------------------------------------------------
On 2006-10-25T14:25:11+00:00 Freedesktop wrote:
*** Bug 8764 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/43
------------------------------------------------------------------------
On 2006-10-31T03:02:08+00:00 Drahflow wrote:
Seems like I have a similar problem, only now cairo spills some error
messages about not supporting 8-bit visuals.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/44
------------------------------------------------------------------------
On 2006-11-20T12:40:11+00:00 Florian-heigl wrote:
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 :))
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/45
------------------------------------------------------------------------
On 2006-11-21T14:36:28+00:00 Freedesktop wrote:
*** Bug 9115 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/46
------------------------------------------------------------------------
On 2006-12-08T09:50:09+00:00 Freedesktop wrote:
*** Bug 9283 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/47
------------------------------------------------------------------------
On 2006-12-23T17:57:18+00:00 Eth0-o2 wrote:
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 0x061b5560 in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#23 0x049eab7a in gtk_drag_begin_internal (widget=0x8885c018, site=0x0,
target_list=0x87b135c0, actions=46, button=1, event=0x829d96a8)
at gtkdnd.c:2262
#24 0x049eaf40 in gtk_drag_begin (widget=0x8885c018, targets=0x87b135c0,
actions=46, button=1, event=0x829d96a8) at gtkdnd.c:2378
#25 0x1c0b1348 in nautilus_icon_container_request_update_all ()
#26 0x1c0a7fdf in nautilus_file_is_gone ()
#27 0x0488532e in _gtk_marshal_BOOLEAN__BOXED (closure=0x8a7328d0,
return_value=0xcf7e0a50, n_param_values=2, param_values=0xcf7e0bb0,
invocation_hint=0xcf7e0a78, marshal_data=0x1c0a7e00) at gtkmarshalers.c:84
#28 0x061a61e6 in g_cclosure_new_swap ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#29 0x061a5f6e in g_closure_invoke ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#30 0x061b5b3b in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#31 0x061b5051 in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#32 0x061b548b in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.1200.4
#33 0x049d00f7 in gtk_widget_event_internal (widget=0x8885c018,
event=0x829d96a8) at gtkwidget.c:3911
#34 0x049cfc8d in gtk_widget_event (widget=0x8885c018, event=0x829d96a8)
at gtkwidget.c:3717
#35 0x048839c5 in gtk_propagate_event (widget=0x8885c018, event=0x829d96a8)
at gtkmain.c:2188
#36 0x048825c4 in gtk_main_do_event (event=0x829d96a8) at gtkmain.c:1422
#37 0x0add15d1 in gdk_event_dispatch (source=0x88f6c040, callback=0,
user_data=0x0) at gdkevents-x11.c:2320
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/48
------------------------------------------------------------------------
On 2007-01-09T21:30:10+00:00 Freedesktop wrote:
*** Bug 9587 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/49
------------------------------------------------------------------------
On 2007-03-19T04:52:25+00:00 Freedesktop wrote:
Patch used in Sun's JDS: http://cvs.opensolaris.org/source/xref/jds
/spec-files/trunk/patches/cairo-02-8bit-fix.diff
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/51
------------------------------------------------------------------------
On 2007-03-31T23:10:53+00:00 Freedesktop wrote:
*** Bug 10460 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/52
------------------------------------------------------------------------
On 2007-04-01T10:52:05+00:00 Freedesktop wrote:
*** Bug 10469 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/53
------------------------------------------------------------------------
On 2007-04-03T12:49:14+00:00 Freedesktop wrote:
*** Bug 10516 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/54
------------------------------------------------------------------------
On 2007-04-05T11:30:53+00:00 Freedesktop wrote:
*** Bug 10532 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/55
------------------------------------------------------------------------
On 2007-04-06T13:26:36+00:00 Dan McMahill wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/56
------------------------------------------------------------------------
On 2007-04-06T16:39:19+00:00 Cpalmer-maths wrote:
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...
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/57
------------------------------------------------------------------------
On 2007-04-06T17:39:48+00:00 Carl Worth wrote:
(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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/58
------------------------------------------------------------------------
On 2007-04-06T18:19:06+00:00 Dan McMahill wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/59
------------------------------------------------------------------------
On 2007-04-10T08:34:36+00:00 Freedesktop wrote:
*** Bug 10588 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/60
------------------------------------------------------------------------
On 2007-05-03T00:40:13+00:00 Brian-cameron-oracle wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/61
------------------------------------------------------------------------
On 2007-06-06T15:26:09+00:00 Carl Worth wrote:
*** Bug 10947 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/62
------------------------------------------------------------------------
On 2007-06-08T16:19:14+00:00 Carl Worth wrote:
*** Bug 11202 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/63
------------------------------------------------------------------------
On 2007-06-08T17:01:17+00:00 Carl Worth wrote:
*** Bug 11175 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/64
------------------------------------------------------------------------
On 2007-07-12T05:16:33+00:00 Zuh wrote:
*** Bug 11405 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/65
------------------------------------------------------------------------
On 2007-08-09T22:16:15+00:00 idefix wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/66
------------------------------------------------------------------------
On 2007-08-09T22:17:10+00:00 idefix wrote:
Created an attachment (id=11071)
Revise the patch to support 8bit truecolor also
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/67
------------------------------------------------------------------------
On 2007-08-21T17:33:18+00:00 Carl Worth wrote:
*** Bug 11745 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/68
------------------------------------------------------------------------
On 2007-08-21T17:34:06+00:00 Carl Worth wrote:
*** Bug 11926 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/69
------------------------------------------------------------------------
On 2007-08-21T17:34:31+00:00 Carl Worth wrote:
*** Bug 12010 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/70
------------------------------------------------------------------------
On 2007-11-28T12:35:32+00:00 Carl Worth wrote:
*** Bug 13386 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/71
------------------------------------------------------------------------
On 2007-12-10T13:27:42+00:00 Thayes77 wrote:
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?
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/72
------------------------------------------------------------------------
On 2007-12-13T11:17:54+00:00 Carl Worth wrote:
*** Bug 13642 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/73
------------------------------------------------------------------------
On 2008-01-03T05:47:15+00:00 Marek-rouchal wrote:
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...
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/74
------------------------------------------------------------------------
On 2008-01-04T03:20:52+00:00 Marek-rouchal wrote:
(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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/75
------------------------------------------------------------------------
On 2008-01-04T04:41:09+00:00 Freedesktop wrote:
Thanks Marek. Can you attach a screenshot?! I'm curious how it looks.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/76
------------------------------------------------------------------------
On 2008-01-04T05:09:20+00:00 Marek-rouchal wrote:
Created an attachment (id=13517)
screenshot of firefox on 256 color (depth 8) display
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/77
------------------------------------------------------------------------
On 2008-01-18T04:18:20+00:00 Fboiteux wrote:
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 :-(
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/78
------------------------------------------------------------------------
On 2008-02-01T04:27:47+00:00 Ashish wrote:
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)
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/79
------------------------------------------------------------------------
On 2008-02-06T01:33:49+00:00 Ashish wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/80
------------------------------------------------------------------------
On 2008-02-06T09:41:07+00:00 Freedesktop wrote:
(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?
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/81
------------------------------------------------------------------------
On 2008-02-09T21:21:16+00:00 Stefan Schmidt wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/82
------------------------------------------------------------------------
On 2008-02-20T01:23:16+00:00 Adrian Johnson wrote:
*** Bug 12283 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/83
------------------------------------------------------------------------
On 2008-03-20T17:29:51+00:00 Carl Worth wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/84
------------------------------------------------------------------------
On 2008-05-22T22:21:20+00:00 Fboiteux wrote:
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 ?
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/87
------------------------------------------------------------------------
On 2008-05-22T22:23:27+00:00 Fboiteux wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/88
------------------------------------------------------------------------
On 2009-02-12T00:31:30+00:00 Marek-rouchal wrote:
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!
Reply at: https://bugs.launchpad.net/libcairo/+bug/61303/comments/89
** Changed in: libcairo
Importance: Unknown => Critical
** Bug watch added: freedesktop.org Bugzilla #5846
http://bugs.freedesktop.org/show_bug.cgi?id=5846
--
gtk apps segfault on gnome 'Human' theme, only from XDMCP
https://bugs.launchpad.net/bugs/61303
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for libcairo.
