From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 9E06C3857C75 for ; Sun, 2 May 2021 14:41:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9E06C3857C75 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-569-f2uWedBXMFC2UXbctJzwBg-1; Sun, 02 May 2021 10:41:57 -0400 X-MC-Unique: f2uWedBXMFC2UXbctJzwBg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 41673107ACC7; Sun, 2 May 2021 14:41:56 +0000 (UTC) Received: from host1.jankratochvil.net (unknown [10.40.192.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C45E5D6AD; Sun, 2 May 2021 14:41:55 +0000 (UTC) Date: Sun, 2 May 2021 16:41:52 +0200 From: Jan Kratochvil To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb Message-ID: References: <547bc1ec-ffa3-2705-39ca-a6d65056461d@polymtl.ca> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.6 (2021-03-06) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2021 14:42:01 -0000 On Sun, 02 May 2021 16:30:19 +0200, Simon Marchi wrote: > On 2021-05-02 9:56 a.m., Jan Kratochvil wrote:> On Sun, 02 May 2021 15:39:12 +0200, Simon Marchi wrote: > > 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. Updated below. Jan 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. There could be 14 operators new but there are only 4, GDB uses 3 of them. There could be 16 operators delete but there are only 6, GDB uses 2 of them. It depends on libraries and compiler which of the operators will get used. Currently being used: U operator new[](unsigned long) U operator new(unsigned long) U operator new(unsigned long, std::nothrow_t const&) U operator delete[](void*) U operator delete(void*, unsigned long) gdbsupport/ 2021-05-02 Jan Kratochvil * new-op.cc (opertor delete 6x): New. diff --git a/gdbsupport/new-op.cc b/gdbsupport/new-op.cc index 5ab19621a43..2f4c71457b1 100644 --- a/gdbsupport/new-op.cc +++ b/gdbsupport/new-op.cc @@ -92,4 +92,46 @@ 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 and then one would + get false positive alloc-dealloc-mismatch (malloc vs operator delete []) + errors from AddressSanitizers. */ + +void +operator delete (void *p) +{ + free (p); +} + +void +operator delete (void *p, const std::nothrow_t&) noexcept +{ + return ::operator delete (p); +} + +void +operator delete (void *p, std::size_t) noexcept +{ + return ::operator delete (p, std::nothrow); +} + +void +operator delete[] (void *p) +{ + return ::operator delete (p); +} + +void +operator delete[] (void *p, const std::nothrow_t&) noexcept +{ + return ::operator delete (p, std::nothrow); +} + +void +operator delete[] (void *p, std::size_t) noexcept +{ + return ::operator delete[] (p, std::nothrow); +} + #endif