| Summary: | [abrt] evolution-3.2.2-1.fc16: camel_folder_get_parent_store: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Harmanec <davidhec> | ||||||||||||||||||
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||||||||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||
| Version: | 16 | CC: | lucilanga, mbarnes, mcrha, mtoman | ||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||
| Hardware: | i686 | ||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||
| Whiteboard: | abrt_hash:c8ca11f097d422740bcffb0fba80994344237baf | ||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||
| Last Closed: | 2012-01-03 16:34:50 UTC | Type: | --- | ||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
David Harmanec
2011-12-19 15:05:16 UTC
Created attachment 548613 [details]
File: gconf_subtree
Created attachment 548614 [details]
File: dso_list
Created attachment 548615 [details]
File: maps
Created attachment 548616 [details]
File: backtrace
Created attachment 548617 [details]
File: xsession_errors
Thanks for a bug report. It is possible that this happened while folder had been updated, unfortunately the backtrace is missing debug symbols for evolution-data-server and evolution, to know for sure. I suppose it happened when you updated your system, but the debug info packages were not updated, thus a mismatch happened here (the package versions are probably different). Please update debug info packages at least for evolution and evolution-data-server and update the backtrace. Thanks in advance. To see whether it works you can do two things: a) The command $ rpm -q evolution evolution-debuginfo may show same versions for both packages (similar for evolution-data-server) b) when you check the backtrace from ABRT report you may not see there lines like this one: > warning: File "/usr/lib/libcamel-provider-1.2.so.29.0.0" has a different > build-id, file skipped and the backtrace should not show this: > #0 0x43b25064 in camel_folder_get_parent_store () from /usr/lib/ > libcamel-provider-1.2.so.29 (note the library name) but rather file name and line number, like here: > #2 0x41efcce0 in g_timeout_dispatch (source=0xb08311b8, callback=0x43b19ca0, > user_data=0xb0845270) at gmain.c:3891 Right now I am not at the computer where this happened and will be back at work only after Christmas. I used ABRT to generate the report and used the option to generate backtrace remotely. So I didn't download the debuginfo packages locally. Is it possible that there was a problem with the virtual host used to generate the report? Would it be sufficient to re-run the backtrace remote generation one more time? To be honest I do not know, I'm not an ABRT developer. I'm CC'ing one ABRT developer for his opinion. Yes, the problem was on the server side. Basically you can try re-running the analysis and search the new backtraces for the lines from comment #6. I would like to say it will help, however the probability is low. Shortly, the problem is caused by yum's lazy dependency resolution - even if you specify exact versions of packages, it often installs a slightly different set. There is an RFE for Retrace Server about not using yum for this, however the implementation is not trivial and still requires some effort. What I can do now is just increasing the priority for this issue. OK, I understand. When I get back to work after Christmas I will first try to regenerate the backtrace remotely. If it again doesn't work, I'll bite the bullet and download the debuginfo packages and do it locally. Either way I should be able to provide better data. Created attachment 549820 [details]
backtrace file
New locally generated backtrace file.
Created attachment 549821 [details]
debuginfo conflicts log
I did as promised but with limited success. As you have predicted, the new attempt to generate the backtrace remotely was no better than the first time.So, I generated the backtrace locally. However, I was not able to install all needed debuginfo files (see the attachment 549821 [details]). I hope this version would be more helpful. Please, let me know if I should do something differently.
Thanks for the update. The backtrace is nice, all debug information from evolution and evolution-data-server is included, together with glibc. The crashing thread is trying to allocate 23 bytes, which fails for some memory corruption and aborts the application. From what I see it is opening your On This Computer folder structure while it crashes. Maybe there's something wrong with ~/.local/share/evolution/mail/local/folders.db file, though it's unlikely, because the values being shown in the backtrace seems valid. Could you try to run evolution under valgrind, which will check for invalid memory operations and will log them, please? The run will be significantly slower, due to all checking. The command is: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt Note that valgrind can avoid certain crashes and logs about them instead, thus even if the application will not be aborted, then the log.txt file can contain the information about faulty memory operation. Created attachment 550379 [details]
Valgrind run log
The requested log is attached.
Thanks for the update. I see from the valgrind log a very nice backtraces for gconf-dbus and usual font-config issues. Apart of that nothing, thus I suppose the issue wasn't reproduced during that run. Maybe the issue is related to some timing, and when it's run under valgrind, with significantly slower processing, the timing is not happening and evolution doesn't crash. Oh, that's an misunderstanding. The crash hasn't happened recently again. It was not reproducible from the beginning. I guess, if you cannot get anything useful from the backtrace and logs we can probably close the bug. That's pity. I appreciate your help with this, and if nothing else then I made a patch to fix the issue with gconf, reported in your valgrind log, but with respect of the initial crash of evolution I didn't find anything related in it. I'm sorry for wasting your time. and I'm closing this for now, but feel free to reopen if you find a way to reproduce this. |