Hide Forgot
Description of problem: Found this backtrace in .xsession-errors: *** glibc detected *** evolution: malloc(): memory corruption: 0x0ced0e80 *** *** glibc detected *** evolution: malloc(): memory corruption: 0x0ced0e80 *** ======= Backtrace: ========= /lib/libc.so.6[0x4f9a7d22] /lib/libc.so.6[0x4f9a9e02] ======= Backtrace: ========= /lib/libc.so.6(__libc_malloc+0x65)[0x4f9ac1a5] /lib/libglib-2.0.so.0[0x4fbe16c4] /lib/libc.so.6[0x4f9a7d22] /lib/libc.so.6[0x4f9a9e02] /lib/libglib-2.0.so.0(g_realloc+0x2b)[0x4fbe1eeb] /lib/libc.so.6(__libc_calloc+0xaf)[0x4f9ad39f] /lib/libglib-2.0.so.0[0x4fbe16f4] /lib/libglib-2.0.so.0(g_malloc0+0x2a)[0x4fbe1e6a] /usr/lib/libcamel-1.2.so.31(camel_block_file_get_block+0x138)[0x464e4b08] /usr/lib/libcamel-1.2.so.31(camel_partition_table_lookup+0xdd)[0x4654093d] /usr/lib/libcamel-1.2.so.31[0x4656f01b] /usr/lib/libcamel-1.2.so.31(camel_index_has_name+0x94)[0x4651b124] /usr/lib/evolution-data-server/camel-providers/libcamellocal.so(+0x17f57)[0xafef57] /usr/lib/evolution-data-server/camel-providers/libcamellocal.so(camel_local_summary_check+0x2b)[0xaf14db] /lib/libglib-2.0.so.0[0x4fbadeb9] /lib/libglib-2.0.so.0(g_ptr_array_sized_new+0x5a)[0x4fbaea1a] /usr/lib/evolution/3.4/libevolution-mail.so.0(+0xa0ddd)[0x246ddd] /usr/lib/evolution/3.4/libevolution-mail.so.0(+0x93fb6)[0x239fb6] /lib/libglib-2.0.so.0[0x4fc0002f] /usr/lib/evolution-data-server/camel-providers/libcamellocal.so(+0x18be6)[0xaffbe6] /usr/lib/evolution-data-server/camel-providers/libcamellocal.so(camel_local_summary_sync+0x33)[0xaf1513] /lib/libglib-2.0.so.0[0x4fbff654] /lib/libpthread.so.0[0x4fae6cd3] /lib/libc.so.6(clone+0x5e)[0x4fa247ce] Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Thanks for a bug report, but I'm afraid I cannot do much with this without any reproducible steps. The backtrace is also not much useful (the glib backtraces use to be of this kind). Furthermore, I doubt this is Fedora specific, thus it would be better to deal with this upstream (I didn't find any similar opened bug there, though).
I think the evolution crashing bug in Fedora 16 is a big enough issue that this bug should be reopened, or if not this one, there should be a common bug to attach all the similar types. In my case it is easy to reproduce. Please advise the best way to continue.
A behavior that I can't explain but may help others is to run from the command line. If I select the mail icon, it crashes almost immediately, but if type evolution in a terminal it will run for 3 or 4 hours without crashing, although it spews stuff in the background sometimes.
evolution: malloc.c:2949: __libc_malloc: Assertion `!victim || ((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x2) || ar_ptr == (((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x4) ? ((heap_info *)((unsigned long)(((mchunkptr)((char*)(victim) - 2*(sizeof(size_t))))) & ~((2 * (512 * 1024))-1)))->ar_ptr : &main_arena)' failed. Aborted (core dumped) [ ~]$ evolution (evolution:5138): evolution-network-manager-WARNING **: network_manager_query_state: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.NetworkManager.service' for details. Error: Unknown Metadata type: '???' (evince:7218): Gtk-WARNING **: gtkcontainer.c:919: container class `GtkScrolledWindow' has no child property named `top-attach' (evince:7218): Gtk-WARNING **: gtkcontainer.c:919: container class `GtkScrolledWindow' has no child property named `top-attach' (evince:7218): Gtk-WARNING **: gtkcontainer.c:919: container class `GtkScrolledWindow' has no child property named `top-attach' Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <rdf:Description rdf:about='da97fde0-6506-11ec-0000-93ef481fb64����uuid:da ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 8 ;uuid:da97fde0-6506-11ec-0000-93ef481fb642011-12-22T17:14:24-05:00�B�`› ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 7 42011-12-22T17:14:24-05:00�B�`›���HT)�BL2011-12-22T17:14:24-05:00�H ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 8 ;uuid:da97fde0-6506-11ec-0000-93ef481fb642011-12-22T17:14:24-05:00�B�`› ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 7 42011-12-22T17:14:24-05:00�B�`›���HT)�BL2011-12-22T17:14:24-05:00�H ^ Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <rdf:Description rdf:about='da97fde0-6506-11ec-0000-93ef481fb64����uuid:da ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 8 ;uuid:da97fde0-6506-11ec-0000-93ef481fb642011-12-22T17:14:24-05:00�B�`› ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 7 42011-12-22T17:14:24-05:00�B�`›���HT)�BL2011-12-22T17:14:24-05:00�H ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 8 ;uuid:da97fde0-6506-11ec-0000-93ef481fb642011-12-22T17:14:24-05:00�B�`› ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 7 42011-12-22T17:14:24-05:00�B�`›���HT)�BL2011-12-22T17:14:24-05:00�H ^ Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <rdf:Description rdf:about='d6b8ab64-6507-11ec-0000-93ef481fb64����uuid:d6 ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <rdf:Description rdf:about='d6b8ab64-6507-11ec-0000-93ef481fb64����uuid:d6 ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <rdf:Description rdf:about='d6b8ab64-6507-11ec-0000-93ef481fb64����uuid:d6 ^ Entity: line 5: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ Entity: line 6: parser error : xmlParseCharRef: invalid xmlChar value 7 b642011-12-22T17:21:27-05:00�B��<	���HT)�BL2011-12-22T17:21:27-05:00�H ^ evolution: malloc.c:2949: __libc_malloc: Assertion `!victim || ((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x2) || ar_ptr == (((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x4) ? ((heap_info *)((unsigned long)(((mchunkptr)((char*)(victim) - 2*(sizeof(size_t))))) & ~((2 * (512 * 1024))-1)))->ar_ptr : &main_arena)' failed. Aborted (core dumped)
(In reply to comment #2) > I think the evolution crashing bug in Fedora 16 is a big enough issue that this > bug should be reopened, or if not this one, there should be a common bug to > attach all the similar types. In my case it is easy to reproduce. Please > advise the best way to continue. I definitely disagree. Software has bugs. Some bugs leads to a crash. Dealing with all bugs in one single bug report is useless. The central place is bugzilla, not bug itself. (In reply to comment #4) > evolution: malloc.c:2949: __libc_malloc: Assertion `!victim || > ((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x2) || ar_ptr > == (((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x4) ? > ((heap_info *)((unsigned long)(((mchunkptr)((char*)(victim) - > 2*(sizeof(size_t))))) & ~((2 * (512 * 1024))-1)))->ar_ptr : &main_arena)' > failed. > Aborted (core dumped) Backtraces count, as they contain information from where the issue was received. ABRT usually catches them for you. I searched for this error message and found bug #766105 for nautilus and a bug #752466 for evolution. I would move your issue under evolution's bug and if you can then follow request from bug #752466 comment #7 especially if you can reproduce it, because I don't seem to be. Also make sure that you've installed debuginfo packages for at least evolution-data-server, evolution and gtkhtml3, plus any other evolution-* packages you have installed and use, thus the valgrind log will contain debug information with source file names and function names. Thanks in advance.