Version-Release number of selected component: evolution-data-server-3.10.4-7.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/libexec/evolution-addressbook-factory crash_function: e_contact_photo_free executable: /usr/libexec/evolution-addressbook-factory kernel: 3.17.4-200.fc20.i686+PAE runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (7 frames) #7 e_contact_photo_free at e-contact.c:2136 #8 book_backend_google_modify_contacts_sync at e-book-backend-google.c:1984 #9 book_backend_modify_contacts_thread at e-book-backend.c:1626 #10 book_backend_dispatch_thread at e-book-backend.c:187 #11 io_job_thread at gioscheduler.c:89 #12 g_task_thread_pool_thread at gtask.c:1245 #14 g_thread_proxy at gthread.c:798
Created attachment 965883 [details] File: backtrace
Created attachment 965884 [details] File: cgroup
Created attachment 965885 [details] File: core_backtrace
Created attachment 965886 [details] File: dso_list
Created attachment 965887 [details] File: environ
Created attachment 965888 [details] File: limits
Created attachment 965889 [details] File: maps
Created attachment 965890 [details] File: open_fds
Created attachment 965891 [details] File: proc_pid_status
Created attachment 965892 [details] File: var_log_messages
Thanks for a bug report. This particular one had been reported already, thus I'm marking it as a duplicate. *** This bug has been marked as a duplicate of bug 1068984 ***
(In reply to Milan Crha from comment #11) > Thanks for a bug report. This particular one had been reported already, thus > I'm marking it as a duplicate. > > *** This bug has been marked as a duplicate of bug 1068984 *** Hrm. Closing this bug out as a duplicate of bug 1068984 shuts everyone that abrt leads to this bug out since bug 1068984 is marked private. Please try to refrain from closing public bugs as duplicate of private bugs since it leaves everyone who is not privileged enough to see the private bug unable to track progress or find patches, etc.
I'm sorry, it wasn't intentional. I guess the bug was marked private only because of an old "bug" in ABRT which did so automatically. I made the other bug public.
I suppose ultimately, Bugzilla ought to warn one when one attempts to close a bug as a duplicate of another bug which has viewing restrictions.
Are we sure this is a duplicate of bug 1068984? Bug 1068984 is closed as upstream bug 725045 and that bug says it was fixed in: Created commit e636dd4 in eds master (3.13.2+) [1] Created commit 683bd3e in eds evolution-data-server-3-12 (3.12.3+) And given the date of my posting in comment 12 that would have been when I hit this bug and that would have been F21 (or very late F20) which should be EDS 3.12.[8-9]. Wouldn't that mean that the fix referenced above should have been in the EDS where I experienced this issue?
This bug is from 3.10.x, thus yes, 3.12.3+ fixes it. I do not know what was your version at the end of the year, neither if it was Fedora 21. The Fedora 20 doesn't have any official 3.12.x evolution* build, only the COPR, which I do not know whether you use or not. Too many unknown things here. ABRT may not point you here if you were on Fedora 21, right?
Ahh. Right. I was running evolution 3.12.8 from a/the COPR, so either way, this happened in evolution 3.12.8 or 3.12.9.
I just tried an update and reboot and it is still broken. F21, yum -y update again this morning, evolution-data-server-3.12.9-2.fc21.i686, kernel 3.17.7-300.fc21.i686+PAE ABRT reported as: https://retrace.fedoraproject.org/faf/reports/457095/
Hmm, okay, the FAF report gathers two different issues, in two different processes (one is in the calendar - bug #1171453, the other one in address book - this bug report). Let's focus on this this crash now, that is in the address book, under e_contact_photo_free(). What address book types do you have configured, please? It can be On The Web, LDAP, Google, .... If you'd have an updated backtrace of the crash, then it'll help too. The previous crash was caused by an update of a Google contact which also had stored a photo, it can be similar, or even the same, but I'd prefer to be sure and see the backtrace (with debuginfo for evolution-data-server being installed, of the same version as the binary package. Please check the backtrace for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).
Milan, how do I force the backtrace to be re-submitted? I installed the debuginfo and rebooted to recreate the coredump again, but when I click Report it just says it has already been reported. I don't use Evolution (I use Thunderbird). When I open Preferences from Evolution Calendar it shows On This Computer:Personal and my gmail account:Contacts Please let me know what you would like as it only takes a reboot to repeat.
Hmm, good question. I do not use ABRT GUI often, thus I do not know. One might be able to use gdb and generate the backtrace from a coredump, but that means that a place where coredumps are saved is known. I do not know the place either. Let's try to do it in a different way. Could you: a) make a copy of ~/.cache/evolution/addressbook/ folder, to have saved the current state for the reproducer b) (since now as root) rename /usr/libexec/evolution-addressbook-factory to /usr/libexec/evolution-addressbook-factory.orig c) create a new text file /usr/libexec/evolution-addressbook-factory with the following content (indentation added for clarity only): #!/bin/bash G_SLICE=always-malloc valgrind --num-callers=20 /usr/libexec/evolution-addressbook-factory.orig &>/tmp/eaf.txt (the above line is one long line with no wrapping) d) make the text file executable: $ chmod a+x /usr/libexec/evolution-addressbook-factory e) then re-login to have the /tmp/eaf.txt populated with information about incorrect memory usage (it's sometimes better than backtrace). Note that you need to have installed also valgrind and that the valgrind can prevent certain crashes, but still log about them, thus even if the addressbook factory will not crash the log may contain valuable information.
I created two, no exception though... [I know logout/in was enough, because I had the exception until I created the 2nd shell for evolution-calendar-factory] $ ps auxw | grep valgr jbuhrt 21615 7.8 3.4 435892 211544 ? Sl 09:00 0:19 valgrind --num-callers=20 /usr/libexec/evolution-calendar-factory.orig $ cat /usr/libexec/evolution-calendar-factory #!/bin/bash G_SLICE=always-malloc valgrind --num-callers=20 /usr/libexec/evolution-calendar-factory.orig &>/tmp/ecf.txt cat /tmp/ecf.txt ==21615== Memcheck, a memory error detector ==21615== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==21615== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==21615== Command: /usr/libexec/evolution-calendar-factory.orig ==21615==
Thanks for the update. Good the calendar factory is "free of issues", though it looks weird, because it use to have some from other libraries it uses. Anyway, the e_contact_photo_free() is used in evolution-addressbook-factory instead.