found 624743 4.6.0-8 thanks Hello,
hurd-i386 is also hit by the bug. Andreas Metzler, le Fri 06 May 2011 20:16:49 +0200, a écrit : > On 2011-05-05 Kees Cook <k...@debian.org> wrote: > > Hi! Thanks for this report. I can't reproduce this segfault. I tried the > > builds both amd64 and i386, and both build fine with 4.6.0-6 for me. Do you > > have any minimal reproducers that might show this more specifically? > > Sadly I cannot reproduce this anymore either. Some of the since > upgraded build-deps must have changed. I can reproduce it with gcc-4.6 4.6.0-8, but only by using valgrind: in debian/minimaltest, prepend valgrind to the line $2 -C "$top/exim4.conf" -bV valgrind will then warn: ==29180== Source and destination overlap in memcpy(0x6fad4e8, 0x6fad4e0, 88) ==29180== at 0x4C25F6A: memcpy (mc_replace_strmem.c:497) ==29180== by 0x13B5D9: init_lookup_list (string3.h:59) ==29180== by 0x11FF6E: main (exim.c:3615) which is the same backtrace reported here. Disassembling init_lookup_list shows this: 0x00000000000335cb <+459>: cltq 0x00000000000335cd <+461>: lea 0x0(,%rax,8),%rdx 0x00000000000335d5 <+469>: callq 0x153a8 <memcpy@plt> 0x00000000000335da <+474>: mov %rbx,%rcx 0x00000000000335dd <+477>: add 0x2b6fac(%rip),%rcx # 0x2ea590 <lookup_list> 0x00000000000335e4 <+484>: mov 0x18(%rsp),%rdx i.e. a memcpy call. l * 0x00000000000335d5 points at 59 return __builtin___memmove_chk (__dest, __src, __len, __bos0 (__dest)); which is actually a memmove call, not a memcpy call! The memmove call comes from the add_lookup_to_list() inline. By replacing it with __builtin_memmove() to avoid the _chk version, I don't get any valgrind issue any more. It looks like gcc-4.6 is here erroneously optimizing __builtin___memmove_chk into a memcpy call! Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523215927.ga3...@const.famille.thibault.fr
