On Tue, 13 Feb 2018 17:31:56 +0100
Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Tue, Feb 13, 2018 at 5:16 PM, Sean McGovern <gsean...@gmail.com> wrote:
> >
> > I discovered this while doing a full valgrind FATE run on a POWER7
> > machine -- among others, fate-noproxy failed.
> >
> > The result for the noproxy test in this case makes me believe it is
> > using the aforementioned behaviour of memcmp():
> >
> > ==47650== Memcheck, a memory error detector
> > ==47650== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> > ==47650== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> > ==47650== Command: /home/seanmcg/build/libav-gcc7/libavformat/tests/noproxy
> > ==47650==
> > ==47650== Invalid read of size 8
> > ==47650==    at 0x1000646C: match_host_pattern (network.c:255)
> > ==47650==    by 0x1000646C: ff_http_match_no_proxy (network.c:284)
> > ==47650==    by 0x100059CF: test (noproxy.c:25)
> > ==47650==    by 0x100057BB: main (noproxy.c:34)
> > ==47650==  Address 0x4480054 is 20 bytes inside a block of size 23 alloc'd
> > ==47650==    at 0x40861E4: malloc (vg_replace_malloc.c:298)
> > ==47650==    by 0x4088AD3: realloc (vg_replace_malloc.c:785)
> > ==47650==    by 0x100A9A2F: av_realloc (mem.c:116)
> > ==47650==    by 0x100A9A2F: av_strdup (mem.c:215)
> > ==47650==    by 0x10006267: ff_http_match_no_proxy (network.c:272)
> > ==47650==    by 0x100059CF: test (noproxy.c:25)
> > ==47650==    by 0x100057BB: main (noproxy.c:34)
> > ==47650==
> >
> > <..snipped for brevity, pattern repeats for each test..>
> >
> > I found the following bug reports which seemed relevant in the GCC Bugzilla:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171 and
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257
> >
> > I don't think this is a compiler bug or cargo-culting, although Clang
> > does not appear to exhibit this behaviour.
> >  
> 
> How is this not a compiler bug if valid C code results in an
> out-of-bounds access due to some optimization?

Isn't it just because they use SIMD (as long as they're within page
boundaries)? Of course it's going to set up some analyzers if they're
not aware of it.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to