+++ This bug was initially created as a clone of Bug #641592 +++

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)

  ... [ other two traces elided from clone ] ...


--- Additional comment from schwab on 2010-10-11 05:15:01 EDT ---

valgrind needs to adapt, none are bugs, just read-ahead.

--- Additional comment from dwmw2 on 2010-10-11 07:07:22 EDT ---

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?