Re: [patch] Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-05-02 9:56 a.m., Jan Kratochvil wrote:> On Sun, 02 May 2021 15:39:12 +0200, Simon Marchi wrote:
>> Please make sure to include all the relevant information about the issue
>> you observed in the commit message.  It's really not clear by reading it
>> what's the problem and why your change fixes it.
> 
> I was not aware GDB has changed the commit log format:
> 
> ------------------------------------------------------------------------------
> 
> Currently for a binary compiled normally (without -fsanitize=address) but with
> LD_PRELOAD of ASAN one gets:
> 
> $ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
> =================================================================
> ==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570
>     #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7)
> ...
> 0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572)
> allocated by thread T0 here:
>     #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f)
>     #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81)
> SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*)
> ==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
> ==1909567==ABORTING
> 
> Despite the code called properly operator new[] and operator delete[].
> But GDB's new-op.cc provides its own operator new[] which gets translated into
> malloc() (which gets recongized as operatore new(size_t)) but as it does not
> translate also operators delete[] Address Sanitizer gets confused.
> 
> The question is how many variants of the delete operator need to be provided.
> Currently GDB does not call the nothrow delete operators (but it calls nothrow
> new operators).

I'm not very familiar with the nothrow concept, so I can't really tell
whether this is OK.  I would give my LGTM to the patch, but because of
this bit let's wait a bit to see if anybody else has something to say.
If there's no news in a week, then that's ok to push.

> 
> gdbsupport/
> 2021-05-02  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* new-op.cc (opertor delete 6x): New.
> 
> diff --git a/gdbsupport/new-op.cc b/gdbsupport/new-op.cc
> index 5ab19621a43..f70d3ef191d 100644
> --- a/gdbsupport/new-op.cc
> +++ b/gdbsupport/new-op.cc
> @@ -92,4 +92,44 @@ operator new[] (std::size_t sz, const std::nothrow_t&) noexcept
>  {
>    return ::operator new (sz, std::nothrow);
>  }
> +
> +/* Define also operators delete as one can LD_PRELOAD=libasan.so.*
> +   without recompiling the program with -fsanitize=address . */

Here, just add the precision that it is to prevent
alloc_dealloc_mismatch errors that we do this.

Thanks,

Simon