Evolution segfaults when I try to add a signature to a mail account. This was reported by at least one other person on #gentoo (user name leio). Reproducible: Always Steps to Reproduce: 1. Emerge evolution 2. Start evo and create a mail account 3. In the main screen, go to "Tools / Settings", select your account and click the "Edit" button 4. In the "Identity" pane, click the "Add New Signature" button. Actual Results: Evolution crashes with a segmentation fault. Expected Results: You should get a dialog allowing you to choose a signature (I believe it's a file chooser window) When I run the program in gdb I get this message: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4356)] 0x40d5d098 in gtk_notebook_set_current_page () from /usr/lib/libgtk-x11-2.0.so.0 Re-emerging gtk+ didn't help, nor did re-emerging evolution with USE="-gtk2" I've seen references to this problem before but wasn't able to find a resolution in Google. Additionally, I just moved over from Red Hat and Evolution was completely stable there when downloading the Ximian Red Carpet version. Thanks for your help. It's not like it's eating my hard drive or anything but I would like to get this to work.
give stuff like 'emerge info' please. What exact evolution version are you talking about btw ? What references are you talking about btw ? Can you give any relevant links ? Setting -gtk2 makes no sense here, if you use evolution 1.4 (which i assume you do) it is gtk2. You cant change that by setting a USE flag, those are about _optional_ compile time options. The backtrace you give is pretty much useless, add 'inherit debug' to the evolution ebuild and recompile with low optimizations to get a better one. You should also get it from all threads, but i don't know the exact gdb command for that. Bug buddy can do that for you.
> give stuff like 'emerge info' please. What exact evolution version are you > talking about btw ? This is Evolution 1.4.3. Sorry, I should have added that information, but I filed the bug early in the morning after staying up late trying to fix it on my own, well before any sort of caffeination. > What references are you talking about btw ? Can you give any relevant links ? I did a search for various combinations of "evolution crash signature libgtk-x11" in google. The single reference that made any sense was completely inconclusive (ended in mid-thread without a resolution). I will see if I can find it again when I get home from work. The other link was anecdotal (chatting with leio on #gentoo last night, who has the same problem). > Setting -gtk2 makes no sense here, if you use evolution 1.4 > (which i assume you do) it is gtk2. You cant change that by setting a USE > flag, those are about _optional_compile time options. Somewhere along the way, there was a notice that some packages had problems with gtk2 and to try -gtk2 if you had problems. So, not really knowing any better and figuring it was worth an hour to try, I did. See below. > The backtrace you give is pretty much useless, add 'inherit debug' to the > evolution ebuild and recompile with low optimizations to get a better one. > You should also get it from all threads, but i don't know the exact > gdb command for that. Bug buddy can do that for you. I'll see what I can do. I'm a Perl programmer with minimal exposure to C/C++, and I barely know how to type "gdb" and get any kind of output, much less what libraries are used to compile what stuff or how to get a useful backtrace. I will see if I can figure out how to reoptimize and reimplement the ebuild later, again, when I have the time to do it. Thank you for your help, I do pretty well with Perl, but when it comes to the other stuff, I just sort of wave the wand, chant the words and hope for the best.
Some more information on this bug: I tried running a binary of Evolution 1.4.3 from my previous distribution (Redhat 8, Evolution obtained through Ximian Red Carpet) and I got the segmentation fault. So, I decided to try replacing /usr/lib/libgtk-x11-2.0.so.0.200.2 with the version from Red Hat 8, and the segmentation fault went away. So, the problem appears to lie with the libgtk-x11 library, not evolution itself. I have therefore amended the title of the bug. I will do more investigation, recompilation, etc. on libgtk to see if I can track down the error any further.
in that case this might be a gtk+-2.2.2 problem, try 2.2.1 instead. You still haven't posted your 'emerge info' btw
> in that case this might be a gtk+-2.2.2 problem, try 2.2.1 instead. How do I mask out 2.2.2? Will that give me a file by the same name? (e.g. libgtk-x11-blahblahblah)? > You still haven't posted your 'emerge info' btw Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20-gentoo-r5 i686 AMD Athlon(tm) XP 2000+ GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo " CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups encode foomaticdb gif jpeg libg++ libwww mad mikmod mmx ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts svga tcltk java guile sdl gpm tcpd pam esd imlib gtk qt motif opengl mozilla cdr gnome -kde alsa python perl oggvorbis gtk2 ssl X mpeg" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=athlon-xp -O3 -pipe" CXXFLAGS="-mcpu=athlon-xp -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
you can just emerge another version by invoking the ebuild you want directly. 'emerge <path to ebuild version>'
A bit more information: OK, I figured out that by not using "~x86" Gentoo goes back to 2.2.1, which works. So, at this point I have 2.2.1 fron Gentoo, which works, 2.2.2 from another distribution, which works, and 2.2.2-r1 from Gentoo, which does not work. More news as it happens.
hmm time to bring this upstream.. *knocks on his head to remind*
*** This bug has been marked as a duplicate of 22976 ***
