Red Hat Bugzilla – Bug 58739
GNOME panel crashes when "KDE menus" item highlighted
Last modified: 2007-04-18 12:39:10 EDT
Description of Problem: "Everything" install from alpha-7.2-beta1, running on a DS20E with Matrox Millennium II graphics. When running XFree86 under the GNOME desktop, popping the Main menu (under the foot icon) and putting the cursor over the "KDE menus" item in the Main menu, causes an Error box to pop up detailing that Application "panel" has crashed due to segmentation fault. Version-Release number of selected component (if applicable): alpha-7.2-beta1 How Reproducible: every time the KDE menus item is highlighted, as per the description of the problem above Steps to Reproduce: 1. 2. 3. Actual Results: Panel crashes, then is respawned, so as long as you avoid the KDE menus item, everything works fine. Expected Results: should see some KDE menus :-) Additional Information: (JAE) I believe this is not graphics card-specific, as it has also happened with the ELSA card as well.
59110 also reports this same problem.
*** Bug 59110 has been marked as a duplicate of this bug. ***
Doesn't happen on Intel, need to try to reproduce for ia64/s390. I'm told we don't need to fix this for the Alpha port, so am only considering it for Hampton.
Punting from Hampton, gnome-panel is rewritten for the release after, so this bug goes away with GNOME 2.
Do you imply that Red Hat 7.2 for Alpha will get Gnome 2 without any testing whatsoever? You may surprise me in many ways but somehow this is hard to believe. This will not help very much anyway if interfaces will be treated with the same cavalier attitude. Anyway, here is the real problem, and a fix, and it is exactly like predicted in my original report #59110. Function 'iconv' is declared in /usr/include/iconv.h as size_t iconv (iconv_t , char **, size_t *, char **, size_t *);. 'libgnome' is passing there instead pointers to objects of int size. You can get away with such bugs if these sizes happen to differ as called functions scribbles at random over a stack of a caller and shit will likely happen. Forcing spurious conversions on a return value from 'strlen' is also not so hot idea. Here is a fix. --- gnome-libs-1.2.13/libgnome/gnome-dentry.c~ Fri Mar 29 12:29:52 2002 +++ gnome-libs-1.2.13/libgnome/gnome-dentry.c Fri Mar 29 13:30:47 2002 @@ -1074,7 +1074,7 @@ } if (fd != (iconv_t)-1) { gchar *pout, *pin, *str; - gint len, ib, ob; + size_t len, ib, ob; len = strlen (value); I attach also changes to a spec file and this patch with a white space intact. :-) After modifications no traces of a problem with any KDE menus whatsover.
Created attachment 51425 [details] Fix for a bad call from gnome libs
Thanks, Compaq already provided the above size_t patch even,I was planning to integrate into Hampton but had forgotten. There is no Hampton 64-bit beta available right now though, so low priority.
gnome-libs 1.4.1.2.90-12 fixes
Erm,.. very nice Havoc,... unfortunately that was the 7.3 tree 8) I've reapplied the patch to gnome-libs-1.2.13-16 and renamed th package to gnome-libs-1.2.13-16a.src.rpm (/mnt/redhat/beehive/comps/dist/7.2-alpha/gnome-libs/1.2.13-16a/SRPMS) Phil =--=