Hide Forgot
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: 1. 2. 3. 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.
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
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
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.
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.
(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 /var/spool/abrt/<folder-of-a-report> 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.
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.
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.