GNOME Bugzilla – Bug 75597
Panel crashes with an ffb(1) Graphics card using gnome2-Beta-2.
Last modified: 2011-02-04 16:11:52 UTC
Gnome 2.0 Beta-2 (Build 13-Mar-2002) Panel consistently crashes on an ultra 2 with an ffb (1) (creator 3D) type graphics card. (the one that doesn't have Gamma Correction.) . These ffb cards have Default Visual set to Non-Linear Normal Visual (-deflinear false). The workaround is to do: /usr/sbin/ffbconfig -deflinear true But, that workaround is not helpful in cases where many applications needs deflinear to be set to false. Problem is also seen with ffb(2) (Creator 3D, usually with Ultra2) and afb(Elite 3D, usually with Ultra-60) cards. Here is the stack trace: t@1 (l@1) terminated by signal SEGV (no mapping at the fault address) Current function is convert_real_slow 1238 *o++ = cmap->colors[pixel].red; (dbx)where current thread: t@1 =>[1] convert_real_slow(image = 0x1e1c00, pixels = 0x1e3170 "", rowstride = 48, x1 = 176, y1 = 0, x2 = 191, y2 = 13, cmap = 0x12ffc0, alpha = 0), line 1238 in "gdkpixbuf-drawable.c" [2] rgbconvert(image = 0x1e1c00, pixels = 0x1e3170 "", rowstride = 48, alpha = 0, x = 176, y = 0, width = 15, height = 13, cmap = 0x12ffc0), line 1387 in "gdkpixbuf-drawable.c" [3] gdk_pixbuf_get_from_image(dest = 0x1e1e00, src = 0x1e1c00, cmap = 0x12ffc0, src_x = 176, src_y = 0, dest_x = 0, dest_y = 0, width = 15, height = 13), line 1658 in "gdkpixbuf-drawable.c" [4] gdk_pixbuf_get_from_drawable(dest = 0x1e1e00, src = 0x1e28a8, cmap = 0x12ffc0, src_x = 0, src_y = 0, dest_x = 0, dest_y = 0, width = 15, height = 13), line 1563 in "gdkpixbuf-drawable.c" [5] _wnck_gdk_pixbuf_get_from_pixmap(dest = (nil), xpixmap = 54525955U, src_x = 0, src_y = 0, dest_x = 0, dest_y = 0, width = 15, height = 13), line 1329 in "xutils.c" [6] try_pixmap_and_mask(src_pixmap = 54525955U, src_mask = 54525960U, iconp = 0xffbeeddc, ideal_width = 32, ideal_height = 32, mini_iconp = 0xffbeedd8, ideal_mini_width = 16, ideal_mini_height = 16), line 1362 in "xutils.c" [7] _wnck_read_icons(xwindow = 54526007U, icon_cache = 0x1847a8, iconp = 0xffbeeddc, ideal_width = 32, ideal_height = 32, mini_iconp = 0xffbeedd8, ideal_mini_width = 16, ideal_mini_height = 16), line 1775 in "xutils.c" [8] get_icons(window = 0x1e1fe8), line 893 in "window.c" [9] force_update_now(window = 0x1e1fe8), line 1567 in "window.c" [10] _wnck_window_create(xwindow = 54526007U, screen = 0x157aa8), line 370 in "window.c" [11] update_client_list(screen = 0x157aa8), line 639 in "screen.c" [12] do_update_now(screen = 0x157aa8), line 1057 in "screen.c" [13] update_idle(data = 0x157aa8), line 1074 in "screen.c" [14] g_idle_dispatch(source = 0x1589c0, callback = 0xff3500d0 = &`libwnck-1.so.1`screen.c`update_idle(gpointer data), user_data = 0x157aa8), line 3128 in "gmain.c" [15] g_main_dispatch(context = 0x14c6f8), line 1618 in "gmain.c" [16] g_main_context_dispatch(context = 0x14c6f8), line 2160 in "gmain.c" [17] g_main_context_iterate(context = 0x14c6f8, block = 1, dispatch = 1, self = 0x12fa98), line 2241 in "gmain.c" [18] g_main_loop_run(loop = 0x1d2d40), line 2461 in "gmain.c" [19] gtk_main(), line 881 in "gtkmain.c" [20] main(argc = 2, argv = 0xffbef454), line 245 in "main.c
Is this a gdk-pixbuf problem ? Copying a pixmap to a pixbuf seems to generic that it must be ...
gdkpixbuf-drawable is known to have various problems in big endian mode: http://bugzilla.gnome.org/show_bug.cgi?id=71597 That should be pretty simple for someone with a bit of time to fix, especially if they have access to the system. (The relevant information for this bug report, is not the model of video card, but the details of the visual being used. Of course, Sun has performance work to do on gdk-pixbuf if they ship graphics cards with a visual that ends up in convert_real_slow())
This is possibly borderline urgent... Bharat, what is your feeling on this? It sounds like it will block testing on a /lot/ of Solaris systems, but I may be misunderstanding the problem.
actually this behavior is true only when the X server works on direct color mode and the deflinear is set to false in which case as owen mentioned convert_real_slow() gets called which is causing the crash. We have been able to simulate it on the machine that we have and are currently working on this. I feel it is an easy fix as we have been able to simulate the dump.
The crash may occur in convert_real_slow() for other visual classes too. I have a fix for DirectColor visual class. I have to check with other visual classes. So i will be uploading a patch once i test with other visual classes. Adding myself to the Cc list for further updates to this bug.
Attaching a patch which checks if the depth of the visual for the colormap passed is not equal to the depth of the source drawable. If not equal then a warning will be thrown and a NULL pixbuf is returned by gdk_pixbuf_get_from_drawable () and gdk_pixbuf_get_from_image (). The patch also contains a fix which causes applications to crash when the default visual class is DirectColor. To actually reproduce the problem when the default visual is DirectColor, set the default visual class to DirectColor and either run gtk+/demos/testpixbuf-drawable.c or run gnome-terminal.
Created attachment 7525 [details] [review] Proposed patch
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
*** Bug 75977 has been marked as a duplicate of this bug. ***
i think that 75977 is not a duplicate of this bug though. owen do you think that this patch can make to the cvs? if there are any changes or modifications required, please tell us and we will try to follow it up.
I'm not taking the gdkpixbuf-drawable changes in their current form + if (image->depth != v->depth) + { + return; + } We never silently return on programmer errors like this. ANd I don't see how convert_real_slow() could get called with mismatched visuals. The warnings about incorrect colormap depth could be a reasonable addition to the devel branch. Could you file a separate bug for the gdkcolor-x11.c changes with a patch including just that and a description of what the patch is doing?
*** Bug 70268 has been marked as a duplicate of this bug. ***
I have filed a separate bug for the changes to gdkcolor-x11.c. Its bug #81954. I am attaching another patch to this bug minus the gdkcolor-x11.c changes and plus warnings added in rgbconvert() and convert_real_slow (). I hadnt put these warnings earlier because these were static functions and the warning for the mismatched depths were already being reported by gdk_pixbuf_get_from_drawable and gdk_pixbug_get_from_image. This problem has been fixed by Havoc's changes to libwnck. bug #70628. But would it would be nice to have these warnings in gdk. Then the application would receive these warnings and know that something is wrong.
Created attachment 8512 [details] [review] Modified patch
Similar problem happens on SunBlade100 Please see http://bugzilla.mozilla.org/show_bug.cgi?id=144421 and http://bugzilla.mozilla.org/show_bug.cgi?id=144421#c4
Committed the patch in CVS. Here is the ChangeLog entry Fri Jul 26 16:34:34 2002 Shivram U <shivaram.upadhyayula@wipro.com> * gdk/gdkpixbuf-drawable.c (gdk_pixbuf_get_from_drawable), (gdk_pixbuf_get_from_image), (rgbconvert), (convert_real_slow): Check if depth of the source is not equal to the depth of the colormap passed. (#75597) Closing this bug now
I shouldn't have closed the bug. Sorry about that. There is a dependency on 71597. Reopening the bug. Does everyone feel its ok to close this bug ?
Bugs should cover one issue; this doesn't cover the same issues as bug 71597. Some of the stuff in bug 71597 has been fixed too.
Verified on a build dated 17th September from CVS. Marking bug status as Closed. Thanks.