Description of problem: The latest glibc update (to glibc-2.5-58.el5_6.2), or possibly the glibc-common update of the same version causes Evolution to not lauch from the desktop icon. Attempts to launch from a command line vary in degrees of failure. Version-Release number of selected component (if applicable): 2.5-58.el5_6.2 How reproducible: Fails on all systems for all users Steps to Reproduce: 1. yum update glibc 2. log in as ordinary user and click on Evolution icon Actual results: no Evolution window appears Expected results: expect Evolution window appear Additional info: This is with the 64-bit version of Evolution on 64-bit systems. The version of Evolution is 2.12.3-19
updated to indicate RHEL version, platform and severity
What does it do instead?
Created attachment 490262 [details] Backtrace of crash, after clicking on new mail
After installing the latetest glibc patch evolution crashes, when I click on new mail. Evolution starts fine. I'm on 32-Bit RHEL 5.6.
Andreas, These are all 64-bit systems. With the 64-bit version of Evolution installed, when a user clicks on the icon, although no window appears (and so from the user's viewpoint, nothing happens) the output of 'ps -ef | grep evolution' shows: feldt 17050 1 0 08:57 ? 00:00:00 evolution --component=mail feldt 17068 1 0 08:57 ? 00:00:00 /usr/libexec/evolution-data-server-1.12 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=41 Furthermore, if I uninstall the 64-bit version of Evolution and then reinstall the 32-bit version, Evolution starts and shows its normal window, reads mail and allow one to view mail. However, any attempt to send mail then causes Evolution to crash. (Exactly as described above by Steven.) So, in either case I have a lot of unhappy faculty members! ;-(
More information - the impacts are somewhat random. One user who was completely unable to get Evolution to run yesterday tried today and found that it would open and work EXCEPT for clicking on Reply (which crashed Evolution) while creating a new message worked fine. Another found that it still would not open at all. Another found that it would open but would crash on a Reply or a New Message. My own system is running Evolution without any errors at all today (including being able to Reply, create new messages.) This smacks strongly of memory issues (stack?, heap?)...
evolution-2.12.3-19.el5.x86_64 glibc-2.5-58.el5_6.2.x86_64 After starting evolution from the terminal I get this: *** glibc detected *** evolution: munmap_chunk(): invalid pointer: 0x000000001014dda0 *** ======= Backtrace: ========= /lib64/libc.so.6(cfree+0x166)[0x2b9ddf06b9d6] /usr/lib64/libORBit-2.so.0(ORBit_free_T+0xc0)[0x3de1032fd0] /usr/lib64/libORBit-2.so.0(ORBit_free+0x3b)[0x3de103304b] /usr/lib64/libbonobo-activation.so.4[0x2b9ddc5dac7a] /usr/lib64/libbonobo-activation.so.4(bonobo_activation_activate+0x108)[0x2b9ddc5db438] /usr/lib64/libbonobo-activation.so.4(bonobo_activation_activate_from_id+0x140)[0x2b9ddc5db650] evolution[0x40a85e] evolution[0x40ade2] evolution[0x40db6b] evolution[0x40dccd] evolution[0x415feb] /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1b4)[0x2b9dded86e64] /lib64/libglib-2.0.so.0[0x2b9dded89c9d] /lib64/libglib-2.0.so.0(g_main_loop_run+0x1ca)[0x2b9dded89faa] /usr/lib64/libbonobo-2.so.0(bonobo_main+0x46)[0x2b9ddc10efd6] evolution[0x415bdb] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b9ddf016994] evolution[0x409d49] ======= Memory map: ======== 00400000-0041e000 r-xp 00000000 08:05 6810619 /usr/bin/evolution 0061d000-00621000 rw-p 0001d000 08:05 6810619 /usr/bin/evolution 100a9000-102c8000 rw-p 100a9000 00:00 0 [heap] 35fa200000-35fa202000 r-xp 00000000 08:05 5434390 /lib64/libkeyutils-1.2.so 35fa202000-35fa401000 ---p 00002000 08:05 5434390 /lib64/libkeyutils-1.2.so 35fa401000-35fa402000 rw-p 00001000 08:05 5434390 /lib64/libkeyutils-1.2.so 35fba00000-35fba68000 r-xp 00000000 08:05 8250957 /usr/lib64/libbonoboui-2.so.0.0.0 35fba68000-35fbc68000 ---p 00068000 08:05 8250957 /usr/lib64/libbonoboui-2.so.0.0.0 35fbc68000-35fbc6d000 rw-p 00068000 08:05 8250957 /usr/lib64/libbonoboui-2.so.0.0.0 35fbe00000-35fbe93000 r-xp 00000000 08:05 8249962 /usr/lib64/libgnomeui-2.so.0.1600.0 35fbe93000-35fc093000 ---p 00093000 08:05 8249962 /usr/lib64/libgnomeui-2.so.0.1600.0 35fc093000-35fc099000 rw-p 00093000 08:05 8249962 /usr/lib64/libgnomeui-2.so.0.1600.0 35fc200000-35fc216000 r-xp 00000000 08:05 8250700 /usr/lib64/libgnome-2.so.0.1600.0 35fc216000-35fc415000 ---p 00016000 08:05 8250700 /usr/lib64/libgnome-2.so.0.1600.0 35fc415000-35fc417000 rw-p 00015000 08:05 8250700 /usr/lib64/libgnome-2.so.0.1600.0 3a50600000-3a5060a000 r-xp 00000000 08:05 8251132 /usr/lib64/libhal.so.1.0.0 3a5060a000-3a50809000 ---p 0000a000 08:05 8251132 /usr/lib64/libhal.so.1.0.0 3a50809000-3a5080a000 rw-p 00009000 08:05 8251132 /usr/lib64/libhal.so.1.0.0 3a52600000-3a52607000 r-xp 00000000 08:05 8252563 /usr/lib64/libnotify.so.1.1.0 3a52607000-3a52807000 ---p 00007000 08:05 8252563 /usr/lib64/libnotify.so.1.1.0 3a52807000-3a52808000 rw-p 00007000 08:05 8252563 /usr/lib64/libnotify.so.1.1.0 3c72c00000-3c72c29000 r-xp 00000000 08:05 8250139 /usr/lib64/libfontconfig.so.1.1.0 3c72c29000-3c72e29000 ---p 00029000 08:05 8250139 /usr/lib64/libfontconfig.so.1.1.0 3c72e29000-3c72e33000 rw-p 00029000 08:05 8250139 /usr/lib64/libfontconfig.so.1.1.0 3c72e33000-3c72e34000 rw-p 3c72e33000 00:00 0 3c76200000-3c7622d000 r-xp 00000000 08:05 8252541 /usr/lib64/libgnomecanvas-2.so.0.1400.0 3c7622d000-3c7642c000 ---p 0002d000 08:05 8252541 /usr/lib64/libgnomecanvas-2.so.0.1400.0 3c7642c000-3c7642e000 rw-p 0002c000 08:05 8252541 /usr/lib64/libgnomecanvas-2.so.0.1400.0 3c77200000-3c77218000 r-xp 00000000 08:05 8249961 /usr/lib64/libglade-2.0.so.0.0.7 3c77218000-3c77417000 ---p 00018000 08:05 8249961 /usr/lib64/libglade-2.0.so.0.0.7 3c77417000-3c77419000 rw-p 00
Please try valgrind.
Just so you know this is widespread, it's affecting my users as well. (I don't use evolution so it's not affecting me.) I've been able to reproduce this on every RHEL5 machine I've tried it on, both 32 bit and 64 bit. I tried using valgrind as you said, ... and it didn't fail. Tried it again without valgrind, failed as soon as I clicked on "Send Mail".
I can reproduce the problem on my RHEL 5.6 (32-bit) system. I tested evolution before and after updating to the latest glibc. After the update, clicking on "Send Mail" crashed evolution as has been reported here.
Created attachment 490738 [details] output of valgrind - evolution did not crash I also tried valgrind and then evolution also didn't fail
Created attachment 490868 [details] user .xsession-errors showing gnome-panel crash We have now had users (so far only of our 32-bit systems) report that their Gnome panels are frozen. The .xsession-error files for these users show that gnome-panel has crashed with the initial line stating: *** glibc detected *** gnome-panel: malloc(): memory corruption: 0x09e20e40 *** which is then followed by a backtrace. This does not happen to all users or even all the time to a given user. So, the impact of the glibc update appears to be broader than just the impact on Evolution.
We are seeing identical behaviour on our 32-bit RHEL 5.6 systems with: *** glibc detected *** gnome-panel: malloc(): memory corruption: 0x09e20e40 *** the gnome-panel crashes - not on every login, but most. The evolution issue is occuring on 64-bit systems as well. We have a temporary workaround as follows: sudo yum downgrade glibc\* followed by excluding glibc in /etc/yum.conf until this is fixed. We can quickly duplicate the problem if after running the "yum downgrade", we "yum install glibc\*" so this is easily reproducible.
We are seeing the gnome-panel freeze/crash issue here as well. So far we have only seein it on 32-bit systems. Attaching the output that "bug buddy" produces when it crashes...
Created attachment 491280 [details] bug buddy report of gnome-panel crash
Here is the results of my research into this bug. I have recompiled the glibc 6 different ways. 1 - Patch 249 not applied 2 - Patch 250 not applied 3 - Patch 251 not applied 4 - Patch 252 not applied 5 - Patches 249,250,251,252 not applied 6 - Changed patch 245 back to what it was in glibc-2.5-58, and Patch 249 not applied. (I tried to just change patch 245 back, but then patch 249 wouldn't apply) In all of my tests, evolution failed as before (when pushing the send button), except for test 6. Test 6 worked correctly. So, in summary, in my opinion, there is a bug in the new patch 245. (For those that don't know, patch 245 was changed between glibc-2.5-58 and glibc-2.5-58.el5_6.2 I haven't tracked down the real bug. I'm just sharing my results.
I see that patch 245 is glibc-rh643822.patch. Unfortunately bugzilla #643822 is not accessible. Could someone from Red Hat please tell us if there is any risk factor (vulnerability) by temporarily removing this patch?
I've opened case # 00451533 with Red Hat support on this issue as well.
I've also opened case # 00452071 with Red Hat in regards specifically to the gnome-panel issue on 32-bit systems.
I too have multiple systems that are experiencing this issue and have opened a case # 00452086 with Red Hat.
On a Sempron system (i686) I experienced the issues with evolution crashing and gnome panels not showing some of the times only after I recovered from a broken boot loader (hanging at "GRUB") after the April 15th update on CentOS 5.6. Could it be that the presence of this broken glibc caused this boot loader issue in combination with a kernel update? Apart from the glibc update last Friday's update also contained kernel-2.6.18-238.9.1.el5 and mkinitrd-5.1.19.6-68.el5_6.1 a.o. Has anyone else seen grub breakage in relation to this issue or is this just a coincidence?
Same issue here on 32-bit evolution and gnome panels in 5.6 Evolution crashes on new mail (either the button or the menu item). Output below. Was all rock solid with 5.5 Seems to be non-printing characters in this error line... not sure if that's in the filename when searching for library or just in the error message... /usr/lib/bonobo/monikers/libmoniker_std_2.so�: No such file or directory. [user@hostname~]$ xxd /usr/lib/bonobo/monikers/libmoniker_std_2.so�: No s 0000000: 2f75 7372 2f6c 6962 2f62 6f6e 6f62 6f2f /usr/lib/bonobo/ 0000010: 6d6f 6e69 6b65 7273 2f6c 6962 6d6f 6e69 monikers/libmoni 0000020: 6b65 725f 7374 645f 322e 736f efbf bd3a ker_std_2.so...: 0000030: 204e 6f20 730a No s.
Created attachment 493183 [details] Valgrind log Valgrind log of the following steps: 1. Open evolution 2. New mail (from button) 3. Compose and send mail 4. Close evolution. This works with valgrind running, without valgrind Evolution crashes when clicking the new mail button or selecting File/New/Mail Message menu item.
yum downgrade glibc fixed Evolution and panel problems. Latest version was working fine on my box until today. 32-bit.
gnome-panel was also crashing on my 34-bit Athlon system. Solution: yum downgrade glibc* nscd nss_ldap And adding exclude=glibc*,nscd to /etc/yum.conf I hope a fix will be released real soon.
Evolution run per comment 23 with glibc-2.5-58 and glibc-common-2.5-58. Works fine without valgrind and not getting the "no such file or directory" error. System back to normally stablity (panel works, evolution mail notification popup back to bottom right of screen instead of top left, etc.). [jbradsha@host ~]$ evolution ** (evolution:4168): DEBUG: mailto URL command: evolution --component=mail %s ** (evolution:4168): DEBUG: mailto URL program: evolution libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files Increasing itip formatter search count to 1 Increasing itip formatter search count to 2 Decreasing itip formatter search count to 1 Decreasing itip formatter search count to 0 (evolution:4168): e-data-server-DEBUG: Loading categories from "/home/jbradsha/.evolution/categories.xml" (evolution:4168): e-data-server-DEBUG: Loaded 29 categories index:0 [jbradsha@host ~]$ Hope this helps narrow down the problem.
Is there any news on this? The issue with gnome-panel breaks the desktop pretty bad.
Cannot access the gnome pannel (can see it but not click on it) from any remote X session. A downgrade to the previous glibc and everything works ok.
This errata https://rhn.redhat.com/errata/RHBA-2011-0466.html seems to be the fix... can RH confirm this is for the same issue? (The corrupted library filenames in comment 22 could be due to this). Thanks.
I can verify that glibc.i686 0:2.5-58.el5_6.3 (from https://rhn.redhat.com/errata/RHBA-2011-0466.html) fixes the evolution problem.
Does anyone know if the equivalent glibc update for RHEL 6 has the same problem that was exposed under RHEL 5? We only have one RHEL 6 system and it is our primary server, so we can't mess around to find out... (The test system is still on my "todo" list! ;-) The package would be: glibc-2.12-1.7.el6_0.5 which has the same CVE fixes that the broken glibc had.
still seeing occasional gnome-panel lock-ups. Also, our data acquisition software GDA still crashes with this version, while fully stable with glibc-2.5-49.el5_5.6.i686
*** This bug has been marked as a duplicate of bug 694655 ***
Hi, Bug 694655 doesn't seem to be visible - can some details of it be made available? Thanks Michael
(In reply to comment #34) > > *** This bug has been marked as a duplicate of bug 694655 *** Please do not mark this bug as a duplicate of bug 694655 without ensuring that bug 694655 is accessible to persons on the CC-list of this bug. Either open up bug 694655 or copy the contents thereof to this report and mark bug 694655 as a duplicate of this. <Big sigh!>
*** Bug 697095 has been marked as a duplicate of this bug. ***
*** Bug 696431 has been marked as a duplicate of this bug. ***