Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 886084 - Process /usr/libexec/e-calendar-factory was killed by signal 11 (SIGSEGV)
Summary: Process /usr/libexec/e-calendar-factory was killed by signal 11 (SIGSEGV)
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-12-11 13:38 UTC by Peter H. Jones
Modified: 2012-12-17 14:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-12-17 14:22:58 UTC
Type: Bug

Attachments (Terms of Use)

Description Peter H. Jones 2012-12-11 13:38:50 UTC
Description of problem:
Process /usr/libexec/e-calendar-factory was killed by signal 11 (SIGSEGV)
gives ABRT with unusable backtrace.

Version-Release number of selected component (if applicable):
evolution.x86_64                   3.2.3-3.fc16       @/evolution-3.2.3-3.fc16.x86_64               
evolution-NetworkManager.x86_64    3.2.3-3.fc16       @/evolution-NetworkManager-3.2.3-3.fc16.x86_64
evolution-data-server.x86_64       3.2.3-4.fc16       @/evolution-data-server-3.2.3-4.fc16.x86_64   
evolution-help.noarch              3.2.3-3.fc16       @/evolution-help-3.2.3-3.fc16.noarch          

I note a version mismatch, but yum check-update says my system is up to date.

How reproducible:
Found a bootup.

Steps to Reproduce:
Actual results:
Bug report

Expected results:
No bug report

Additional info:
Found https://bugzilla.gnome.org/show_bug.cgi?id=662068 , but I don't know if it applies. That's why I'm submitting a new, possibly duplicate bug report. Please let me know if you need the files from ABRT.

Comment 1 Milan Crha 2012-12-12 11:54:25 UTC
Thanks for a bug report. I cannot tell from the backtrace whether this is already known or not. Do you have any steps how to reproduce this? Could you install debuginfo packages for evolution-data-server, evolution and any other evolution packages you use, make sure it's of the same version as your binary packages, and then, when/if abrt will catch a report again, then it'll have usable backtrace. You can get debuginfo packages with command like this:
   $ yum update evolution-data-server-debuginfo evolution-debuginfo --enablerepo=*-debuginfo

Comment 2 Peter H. Jones 2012-12-12 13:10:12 UTC
I had to use "yum install" instead of "yum update". As a result, I got (large spacees reduced:
  Installing : evolution-data-server-debuginfo-3.2.3-4.fc16.x86_64           1/2 
  Installing : evolution-debuginfo-3.2.3-3.fc16.x86_64                       2/2 
  Verifying  : evolution-debuginfo-3.2.3-3.fc16.x86_64                       1/2 
  Verifying  : evolution-data-server-debuginfo-3.2.3-4.fc16.x86_64           2/2

Comment 3 Milan Crha 2012-12-13 11:25:57 UTC
Good. Then the next time it'll crash an ABRT backtrace should be usable.  Will you upload it here, or should I close this and you'll open a new bug report? Both works for me.

Comment 4 Peter H. Jones 2012-12-13 13:13:08 UTC
After downloading the debuginfo packages, I tried to submit my existing core dump. I saw:
--- Running analyze_LocalGDB ---
Analyzing coredump 'coredump'
All 55 debuginfo files are available
Generating backtrace
Backtrace is generated and saved, 1588 bytes
Can't open file './component': No such file or directory

The backtrace is still unusable. Otherwise, ABRT might have generated a new bug report.

Comment 5 Milan Crha 2012-12-14 08:17:04 UTC
(In reply to comment #4)
> All 55 debuginfo files are available
> Generating backtrace
> Backtrace is generated and saved, 1588 bytes

Why do you think the backtrace is unusable? Maybe it is, but I would like to see it. The ABRT report folder should have there a 'backtrace' file, of the above size. I think ABRT saves its reports into
If you'll find the report, and the backtrace file, please make sure it'll not contain any private information, like passwords and such. I usually search for "pass" (quotes for clarity only) in the backtrace, to check whether it is password-free.

Comment 6 Peter H. Jones 2012-12-14 14:13:50 UTC
Created attachment 663608 [details]
Backtrace file

The backtrace file shows the coredump to be truncated. My coredump file contains 3932160 bytes. The strings command showed me strings from my personal calendar, so I'd like to make it private.

Comment 7 Milan Crha 2012-12-17 14:22:58 UTC
Thanks for the backtrace. You are right, in this form it's really unusable. Let's wait if you'll face the issue again, and either reopen this or file a new bug report, hopefully with ABRT this time. Thanks for your time on this.

Note You need to log in before you can comment on or make changes to this bug.