| Summary: | [abrt] evolution-2.28.3-24.el6: Process /usr/bin/evolution was killed by signal 6 (SIGABRT) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Red Hat Case Diagnostics <case-diagnostics> | ||||||
| Component: | evolution-mapi | Assignee: | Matthew Barnes <mbarnes> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6.0 | CC: | mcrha, swaikar, tpelka | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | abrt_hash:240151be15f19ac94aa78febd9ce87ab740252a9 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-08-12 11:16:10 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 782183, 960054 | ||||||||
| Attachments: |
|
||||||||
|
Description
Red Hat Case Diagnostics
2011-07-20 18:01:29 UTC
Created attachment 514066 [details]
File: backtrace
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Created attachment 514631 [details]
Backtrace, Dissassembly
New updated backtrace attached (gdb)
#0 0x0000003977232a45 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003977234225 in abort () at abort.c:92
#2 0x000000397726fdfb in __libc_message (do_abort=2, fmt=0x3977355b58 "*** glibc detected *** %s: %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:186
#3 0x0000003977275716 in malloc_printerr (action=3, str=0x3977355eb8 "free(): corrupted unsorted chunks", ptr=<value optimized out>)
at malloc.c:6283
#4 0x0000003977265edd in _IO_new_fclose (fp=0x7fb7d8afe110) at iofclose.c:88
#5 0x00000033842469c2 in camel_store_summary_save (s=0x16e1970) at camel-store-summary.c:472
#6 0x00007fb8022efbb2 in mapi_get_folder_info (store=0x15cd980, top=0x0, flags=7, ex=0x2f2de70) at camel-mapi-store.c:1381
#7 0x0000003384248fa1 in camel_store_get_folder_info (store=0x15cd980, top=0x0, flags=7, ex=0x2f2de70) at camel-store.c:895
#8 0x00007fb809ee442b in emft_get_folder_info__exec (m=0x2f2de50) at em-folder-tree.c:1712
#9 0x00007fb809f0116f in mail_msg_proxy (msg=0x2f2de50) at mail-mt.c:522
#10 0x000000397826360b in g_thread_pool_thread_proxy (data=<value optimized out>) at gthreadpool.c:265
#11 0x0000003978262074 in g_thread_create_proxy (data=0x1ac50c0) at gthread.c:635
#12 0x00000039776077e1 in start_thread (arg=0x7fb7e1920700) at pthread_create.c:301
#13 0x00000039772e68ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Thanks for a bug report and a detailed backtrace (the second attachment). The warning suggests that this is about memory corruption. If you can reproduce this, or you know any steps which can lead to this, could you try to reproduce this under valgrind, please? It's very good in identifying memory issues. You can run evolution like this, to get the valgrind log: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt The only disadvantage is that evolution is pretty slow when running under valgrind. Also, I didn't find a similar upstream bug report, which only means that the memory corruption is "random", in a meaning that the memory is overwritten for different objects. You can try to run valgrind without that G_SLICE=always-malloc, but it's usually better to include it. Even if evolution will not crash (valgrind can avoid certain types of crashes), then the log can contain the information about invalid writes or reads. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. After closer backtrace reading, maybe this is not an evolution-mapi issue, because the Thread 12 also reports a memory issue. Thus this seems more like a ref-counting issue, some function might unref an object which was supposed to not be unreffed there. I tried to reproduce this with evolution-data-server-2.28.3-16 and evolution-2.28.3-30 under valgrind, but it didn't catch anything similar to the backtrace above. I tried changing account properties on POP3 and IMAP accounts, as written at comment #0, but no luck. It;ll be good to get more details from the customer, if he/she is still interested, for more detailed steps and the best a valgrind log, as requested at comment #9. I'm closing this due to lack of response. Please reopen, if you'll see this with 2.32.3+. Thanks in advance. |