I've been running Evolution under valgrind for a while, in F-13. Since updating to F-14 I've started getting a lot of complaints that look like string functions reading off the end of strings... ==24277== Invalid read of size 8 ==24277== at 0x3197D43531: __strcasecmp_l_ssse3 (strcmp.S:215) ==24277== by 0x3F6E45DD6D: ??? (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E45DFFA: ??? (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E4629A6: krb5_mk_req_extended (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E01DB56: ??? (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x3F6E01E37D: ??? (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x3F6E00FD31: gss_init_sec_context (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x66B4BF9: sasl_gssapi_challenge_sync (camel-sasl-gssapi.c:309) ==24277== by 0x66B80DD: camel_sasl_challenge_sync (camel-sasl.c:515) ==24277== by 0x66B85C0: camel_sasl_challenge_base64_sync (camel-sasl.c:628) ==24277== by 0x1C7DECFA: imapx_continuation (camel-imapx-server.c:1812) ==24277== by 0x1C7DEE4F: imapx_step (camel-imapx-server.c:1983) ==24277== Address 0x22fc8a58 is 0 bytes after a block of size 8 alloc'd ==24277== at 0x4A0615D: malloc (vg_replace_malloc.c:195) ==24277== by 0x3197C828A1: strdup (strdup.c:43) ==24277== by 0x3F6E48B3EB: profile_get_string (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E45DFDD: ??? (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E4629A6: krb5_mk_req_extended (in /lib64/libkrb5.so.3.3) ==24277== by 0x3F6E01DB56: ??? (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x3F6E01E37D: ??? (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x3F6E00FD31: gss_init_sec_context (in /lib64/libgssapi_krb5.so.2.2) ==24277== by 0x66B4BF9: sasl_gssapi_challenge_sync (camel-sasl-gssapi.c:309) ==24277== by 0x66B80DD: camel_sasl_challenge_sync (camel-sasl.c:515) ==24277== by 0x66B85C0: camel_sasl_challenge_base64_sync (camel-sasl.c:628) ==24277== by 0x1C7DECFA: imapx_continuation (camel-imapx-server.c:1812) ==24277== Use of uninitialised value of size 8 ==24277== at 0x3197D455E4: __strcasecmp_l_ssse3 (strcmp.S:2257) ==24277== by 0x3199C12F25: ns_samename (ns_samedomain.c:200) ==24277== by 0x3199C0B128: __res_nameinquery (res_send.c:280) ==24277== by 0x3199C0B274: __res_queriesmatch (res_send.c:335) ==24277== by 0x3199C0BEE0: __libc_res_nsend (res_send.c:1248) ==24277== by 0x3199C091F4: __libc_res_nquery (res_query.c:225) ==24277== by 0x3199C097A0: __libc_res_nquerydomain (res_query.c:576) ==24277== by 0x3199C09B6C: __libc_res_nsearch (res_query.c:377) ==24277== by 0x26252213: _nss_dns_gethostbyname4_r (dns-host.c:314) ==24277== by 0x3197CCBC6B: gaih_inet (getaddrinfo.c:716) ==24277== by 0x3197CCEF31: getaddrinfo (getaddrinfo.c:2160) ==24277== by 0x725F708: cs_getaddrinfo (camel-net-utils.c:654) ==24277== Invalid read of size 8 ==24277== at 0x3197C8B60D: _wordcopy_fwd_dest_aligned (wordcopy.c:205) ==24277== by 0x3197C8529D: __GI_memmove (memmove.c:76) ==24277== by 0x3197CB8359: re_string_reconstruct (regex_internal.c:675) ==24277== by 0x3197CC2E28: re_search_internal (regexec.c:829) ==24277== by 0x3197CC8E42: regexec@@GLIBC_2.3.4 (regexec.c:251) ==24277== by 0x725B57F: camel_header_raw_check_mailing_list (camel-mime-utils.c:4519) ==24277== by 0x669E3B0: message_info_new_from_header (camel-folder-summary.c:3503) ==24277== by 0x66A0DF0: camel_folder_summary_info_new_from_parser (camel-folder-summary.c:2666) ==24277== by 0x1C7DAEFA: imapx_untagged (camel-imapx-server.c:1491) ==24277== by 0x1C7DEE65: imapx_step (camel-imapx-server.c:1979) ==24277== by 0x1C7DF12F: parse_contents (camel-imapx-server.c:4770) ==24277== by 0x1C7DF5C5: imapx_parser_thread (camel-imapx-server.c:4816) ==24277== Address 0x2491d328 is 24 bytes inside a block of size 27 alloc'd ==24277== at 0x4A0615D: malloc (vg_replace_malloc.c:195) ==24277== by 0x4A061D7: realloc (vg_replace_malloc.c:476) ==24277== by 0x3197CC2D4B: re_search_internal (regex_internal.c:158) ==24277== by 0x3197CC8E42: regexec@@GLIBC_2.3.4 (regexec.c:251) ==24277== by 0x725B57F: camel_header_raw_check_mailing_list (camel-mime-utils.c:4519) ==24277== by 0x669E3B0: message_info_new_from_header (camel-folder-summary.c:3503) ==24277== by 0x66A0DF0: camel_folder_summary_info_new_from_parser (camel-folder-summary.c:2666) ==24277== by 0x1C7DAEFA: imapx_untagged (camel-imapx-server.c:1491) ==24277== by 0x1C7DEE65: imapx_step (camel-imapx-server.c:1979) ==24277== by 0x1C7DF12F: parse_contents (camel-imapx-server.c:4770) ==24277== by 0x1C7DF5C5: imapx_parser_thread (camel-imapx-server.c:4816) ==24277== by 0x3197869445: g_thread_create_proxy (gthread.c:1897) ==24277==
valgrind needs to adapt, none are bugs, just read-ahead.
I'll buy that argument about the third of the three traces above. Not so convinced on the first though. There was an allocation of 8 bytes, and glibc is reading from the *subsequent* 8 bytes. If the allocation was in the last 8 bytes of a page, then glibc could be reading from the *next* page, which could fault, surely? The second trace is probably similar -- if it was within a genuine allocation and just reading off the end of it (within reason), then I don't think valgrind would be reporting it as it did, would it? It'd look more like the third trace.
While we're at it, it would be good if valgrind would also stop bitching about: ==19653== Thread 15: ==19653== Conditional jump or move depends on uninitialised value(s) ==19653== at 0x3197CBA7CF: re_compile_fastmap_iter.clone.21 (regcomp.c:327) ==19653== by 0x3197CC839B: re_compile_fastmap (regcomp.c:275) ==19653== by 0x3197CC8ADE: regcomp (regcomp.c:511) ==19653== by 0x72550A0: mailing_list_init (camel-mime-utils.c:4483) ==19653== by 0x3197868FF9: g_once_impl (gthread.c:1049) ==19653== by 0x725B4A1: camel_header_raw_check_mailing_list (camel-mime-utils.c:4511)
I've cloned this against glibc as bug 645178, due to comment 2.
*** Bug 645178 has been marked as a duplicate of this bug. ***
The strcasecmp stuff is now fixed in valgrind, the SSE version is too difficult for valgrind to understand.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping