This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Put -lasan always very early on the ld command line (PR sanitizer/55374)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Dmitry Vyukov <dvyukov at google dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 30 Jan 2013 16:12:36 +0100
- Subject: Re: [PATCH] Put -lasan always very early on the ld command line (PR sanitizer/55374)
- References: <20130122165813.GY7269@tucnak.redhat.com> <87k3quiueg.fsf@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jan 30, 2013 at 04:04:55PM +0100, Dodji Seketeli wrote:
> As an aside, I am curious why about ...
>
> > --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj 2012-12-14 16:24:38.000000000 +0100
> > +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C 2013-01-22 16:43:03.337091101 +0100
> > @@ -27,7 +27,7 @@ struct DeepFree<0> {
> > };
> >
> > int main() {
> > - char *x = new char[10];
> > + char *x = (char*)malloc(10);
> > // deep_free(x);
> > DeepFree<200>::free(x);
> > return x[5];
>
> ... why/how this is falling when -lasan comes before -lstdc++?
libasan has added recently support for operator new and operator new[]
checking, which checks that there is not a mismatch between the way
how object is allocated (malloc/calloc/realloc vs. operator new vs. operator
new[]) and how it is deallocated (free vs. delete vs. delete[]). The
deep-stack-uaf-1.C testcase has been violating this (new char[10]
allocation, free (x) deallocation) and has been changed upstream
when those changes landed into libasan. When -lstdc++ came first,
the -lasan operator new interceptor wasn't called (because libstdc++'s
operator new was earlier in search scope) and thus it appeared as calling
malloc and doing free to -lasan.
Jakub