Hide Forgot
libreport version: 2.0.7 abrt_version: 2.0.6 backtrace_rating: 3 cmdline: evolution executable: /usr/bin/evolution kernel: 3.1.5-1.fc16.i686.PAE pid: 19034 pwd: /home/jimg reason: Process /usr/bin/evolution was killed by signal 6 (SIGABRT) time: Sat 17 Dec 2011 09:56:48 PM AKST uid: 1001 username: jimg backtrace: Text file, 155249 bytes build_ids: Text file, 7913 bytes dso_list: Text file, 18898 bytes maps: Text file, 57812 bytes environ: :XDG_VTNR=2 :XDG_SESSION_ID=6 :HOSTNAME=richelieu.localdomain :IMSETTINGS_INTEGRATE_DESKTOP=yes :SHELL=/bin/bash :TERM=dumb :HISTSIZE=1000 :XDG_SESSION_COOKIE=7aaf5182946feaed5853fbbf00000011-1323935075.849072-14454184 :QTDIR=/usr/lib/qt-3.3 :GNOME_KEYRING_CONTROL=/tmp/keyring-QOOoIS :QTINC=/usr/lib/qt-3.3/include :IMSETTINGS_MODULE=none :USER=jimg :USERNAME=jimg :MAIL=/var/spool/mail/jimg :PATH=/usr/lib/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/jimg/bin :DESKTOP_SESSION=gnome :QT_IM_MODULE=xim :PWD=/home/jimg :XMODIFIERS=@im=none :GNOME_KEYRING_PID=3531 :LANG=en_US.utf8 :GDM_LANG=en_US.utf8 :GDMSESSION=gnome :HISTCONTROL=ignoredups :HOME=/home/jimg :XDG_SEAT=seat0 :SHLVL=1 :LOGNAME=jimg :QTLIB=/usr/lib/qt-3.3/lib :DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-gcYBrwEgHL,guid=df3cbe4e9a5e13b7686199f700001e25 :'LESSOPEN=||/usr/bin/lesspipe.sh %s' :WINDOWPATH=2 :XDG_RUNTIME_DIR=/run/user/jimg :DISPLAY=:0 :XAUTHORITY=/var/run/gdm/auth-for-jimg-IX44HS/database :_=/usr/bin/gnome-session :GNOME_DESKTOP_SESSION_ID=this-is-deprecated :SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/3535,unix/unix:/tmp/.ICE-unix/3535 :SSH_AUTH_SOCK=/tmp/keyring-QOOoIS/ssh :GPG_AGENT_INFO=/tmp/keyring-QOOoIS/gpg:0:1 :GJS_DEBUG_OUTPUT=stderr :'GJS_DEBUG_TOPICS=JS ERROR;JS LOG' :DESKTOP_STARTUP_ID=gnome-shell-3729-richelieu.localdomain-evolution-7_TIME263441138 :GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/evolution.desktop :GIO_LAUNCHED_DESKTOP_FILE_PID=19034 var_log_messages: :Dec 11 21:05:30 richelieu yum[13425]: Updated: evolution-data-server-3.2.2-1.fc16.i686 :Dec 11 21:06:58 richelieu yum[13425]: Updated: evolution-3.2.2-1.fc16.i686 :Dec 11 21:11:07 richelieu yum[13425]: Updated: evolution-help-3.2.2-1.fc16.noarch :Dec 11 21:11:33 richelieu yum[13425]: Updated: evolution-NetworkManager-3.2.2-1.fc16.i686 :Dec 13 17:47:53 richelieu yum[9395]: Installed: tracker-evolution-plugin-0.12.7-1.fc16.i686 :Dec 17 21:56:52 richelieu abrt[19135]: Saved core dump of pid 19034 (/usr/bin/evolution) to /var/spool/abrt/ccpp-2011-12-17-21:56:48-19034 (315998208 bytes)
Created attachment 548344 [details] File: backtrace
Created attachment 548345 [details] File: dso_list
Created attachment 548346 [details] File: build_ids
Created attachment 548347 [details] File: maps
Thanks for a bug report. This seems to be quite low in gtk3, on the first look. Could you install debuginfo packages for your currently installed gtk3 version and update the backtrace, if it's reproducible on your side, please? It may help to narrow the issue. Some steps how to reproduce this will be also appreciated. Thanks in advance.
Funny you should say that about gtk3, an update came available on 12/20. The problem was, due to some sort of dependency error with yum, I was unable to install it until I figured out that it wanted cairo-devel installed 1st. I also did not see your message until after I had figured out and updated gtk3, so the updated backtrace is for the current gtk3. I now have gtk3-3.2.2-4 This is not the 1st time I have had dependency issues updating F16. I am told by packagekit to go to YUM's website and report it, but have been unable to find a reporting mechanism on their website. I also didn't know that I had a way to install debuginfo rpms, but I think I figured that out. When I re-ran the backtrace stuff in ABRT, it complained about 8 debuginfo packages it was unable to locate and install. I have no idea what they were about as they seemed to have random numbers for names. When I went through the updating of the bug report in ABRT, it submitted it as a new bug. I didn't know how to stop it. The new bug report is 769787. I don't know how to make it crash. It often seems to do that when it is running in the background. I'm not necessarily even in the room when it does it.
*** Bug 769787 has been marked as a duplicate of this bug. ***
Thanks for the update. Backtrace from bug #769787 shows a different place, but still double-free. That's a good thing, as this might not be gtk3 issue after all. The double-free means that the code tries to free memory which was already freed, in our case, I believe, is problem that some part of the code (either evolution's or any library it uses) freed memory which it shouldn't touch. The thing that it happened for you while evolution is in background suggests that it's something when updating/refreshing folders during automatic check for a new mail. It's usually quite hard to find what is causing such issue, but that it's doing that in background for you may help us a bit. I would like to ask you to run evolution under valgrind, and let it do its stuff. It'll be quite slow anyway, and eating all your CPU, due to all memory checking, but it may help narrow the issue. You can run it with a command like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt Note that valgrind can avoid certain crashes, it logs them, but keeps evolution running, thus even if evolution will not crash, the valgrind log can contain information about the issue. These double-free issues are noted with lines containing "invalid free/delete" message, or similar to that.
I'm not certain I did this correctly, I am unfamiliar w/ valgrind. I entered the command you asked for (copy/paste) after installing valgrind. My x-term became unresponsive after entering the command. Top showed neither valgrind nor Evolution running. I finally attempted starting Evolution separately. It crashed almost immediately w/ abrt showing it was killed by signal 5. This is all that is in "log.txt" (after some 20 minutes): [jimg@richelieu ~]$ cat log.txt ==12121== Memcheck, a memory error detector ==12121== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==12121== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12121== Command: evolution ==12121== [jimg@richelieu ~]$ This was there before running Evolution and remained unchanged afterwards. I will probably have to force a system restart to kill the broken x-term, but will leave it along overnight in case something is going on I'm not seeing.
How do I undo what this command has done to my system? I think this G_SLICE=always-malloc part has set an environment variable to something my system doesn't like. X will no longer come up completely. Jim G
I have been trying to research this, should it have been "Export G_SLICE=always-malloc..." instead of just "G_SLICE=always-malloc..."?
I take that back... I think X is coming up completely. It is likely the stuff that goes with it to make up the desktop that isn't coming up. I am kinda dead in the water here.
This is screwy, but I seem to have it back. Something to do w/ ICEAuthority. You didn't get back to me, so out of desperation I did a fresh install on a 2nd drive. After the install, I re-connected the drive w/ the install I couldn't log in on to copy over the data. I must have gotten something crossed as I accidentally booted up on the drive I couldn't log in on before. Not knowing I was on the old drive, I attempted logging in and was told it couldn't update ICEAuthority and it wouldn't let me log in at all. In researching this problem, I found the recommendation to run: chown [user] -R [user-dir] as root to fix the ICEAuthorty problem. I did this, all while thinking I was on the new drive when I was actually on the old. It worked and I am now able to log in on my original install. Where were we? This doesn't answer what went wrong w/ the G_Slice stuff.
(In reply to comment #14) > You didn't get back to me, so out of desperation I did a fresh install > on a 2nd drive. I'm sorry, I was on Christmas holidays. > This doesn't answer what went wrong w/ the G_Slice stuff. The command, as written in comment #8, means that the G_SLICE=always-malloc is valid only for the valgrind application and nothing else around. You did it right with copy & paste, all should work fine with it. Why the whole system, and the ICEAuthority, broke for you I have no idea, this command works for me all the time, without any such issue. Maybe the valgrind itself did something unexpected. Also the log.txt file, if working properly, should be populated with much more information, but it seems valgrind didn't run successfully the evolution application, for some reason. I'm sorry for so much uncertainty from my side, but I never faced any similar issue with valgrind before.
OK. I will give it a try tomorrow. I have been reading up some more on it and while I don't have a complete handle on it, i do agree that was unexpected behavior. I'm wondering if I accidentally had an Evolution window open when I ran the program. I did close down the open window I knew of, but I have noticed that because of the way Gnome 3 works, I have caught myself with multiple instances running without realizing it.
Created attachment 550333 [details] log.txt greated by Valgrind
I think it ran OK this time. Evolution seemed to get stuck "Checking for new messages". I let it sit for an hour or so, and it never did become usable. ABRT showed a crash almost immediately after starting Evolution. Killed w/ sig 5 (normally gets killed w/ sig 6 wo/ Valgrind). ABRT wanted 120 debuginfo rpms that it couldn't find to run the backtrace, so I don't have that.
I finally had to log out of my user account to kill Evolution. A couple of lines got added to log.txt when I did. The first couple of lines are where I was attempting to kill it and couldn't. ==6165== Received terminate signal... Received terminate signal... Received terminate signal... Received terminate signal... Received terminate signal... Received terminate signal... ==6165== ==6165== HEAP SUMMARY: ==6165== in use at exit: 17,664,646 bytes in 290,375 blocks ==6165== total heap usage: 51,877,146 allocs, 51,586,771 frees, 4,126,894,753 bytes allocated ==6165== ==6165== LEAK SUMMARY: ==6165== definitely lost: 5,647 bytes in 72 blocks ==6165== indirectly lost: 15,235 bytes in 854 blocks ==6165== possibly lost: 7,600,221 bytes in 58,377 blocks ==6165== still reachable: 10,043,543 bytes in 231,072 blocks ==6165== suppressed: 0 bytes in 0 blocks ==6165== Rerun with --leak-check=full to see details of leaked memory ==6165== ==6165== For counts of detected and suppressed errors, rerun with: -v ==6165== Use --track-origins=yes to see where uninitialised values come from ==6165== ERROR SUMMARY: 89 errors from 13 contexts (suppressed: 0 from 0) [jimg@richelieu ~]$
Thanks for the update. I see that the valgrind doesn't work on your machine in the best way. When you have it running from console you can also Ctrl+C to stop it. The attached log doesn't have any debug information, neither from evolution packages, nor from gtk3. I guess it's because some recent update, where only binary packages got updated, but those debuginfo packages left with the old version. Nonetheless, the valgrind log doesn't show anything unusual, as far as I can tell, thus it really seems it run OK this time. Having other instance of evolution running may not cause such crashes, it's a usual thing, and evolution only, in such cases, passes arguments to the already running instance and closes itself. The freeze on new mail check looks suspicious, but likely unrelated to this crash. I might be wrong, but I'm thinking of bug #766352 too. Thus just in case, what is your current version of gtk3, please? To get it and version of evolution-data-server with evolution, just run: $ rpm -q gtk3 evolution-data-server evolution-data-server-debuginfo \ evolution evolution-debuginfo the version of debuginfo package should be the same as its corresponding binary package, thus please make sure they'll match (it'll produce better backtraces). If it was caused by bug #766352, and you have that version of gtk3 installed, then maybe run evolution as usual and see whether the crash will be reproducible.
Do debuginfo rpms show differently than others? [jimg@richelieu ~]$ rpm -q gtk3 evolution-data-server evolution-data-server-debuginfo evolution evolution-debuginfo gtk3-3.2.2-4.fc16.i686 evolution-data-server-3.2.2-2.fc16.i686 package evolution-data-server-debuginfo is not installed evolution-3.2.2-1.fc16.i686 package evolution-debuginfo is not installed [jimg@richelieu ~]$ rpm -qa | grep debuginfo [jimg@richelieu ~]$ I know there are debuginfo rpms on my box, I just watched it install some. But they don't seem to show up the way other rpms do.
Nope, not differently. Your command works for me: gtk3-3.2.2-4.fc16.x86_64 evolution-data-server-3.2.2-2.fc16.x86_64 evolution-data-server-debuginfo-3.2.2-2.fc16.x86_64 evolution-3.2.2-1.fc16.x86_64 evolution-debuginfo-3.2.2-1.fc16.x86_64
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.