From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ClQ+K4a3jmDhIwAAWB0awg (envelope-from ) for ; Sun, 02 May 2021 10:30:30 -0400 Received: by simark.ca (Postfix, from userid 112) id A055C1F11C; Sun, 2 May 2021 10:30:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D0B601E54D for ; Sun, 2 May 2021 10:30:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B6A53835820; Sun, 2 May 2021 14:30:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B6A53835820 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619965829; bh=eeY1c+gmm7QJZQYOo3yjpWfurKArVoAhYA6IJOBATFI=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=o2giGZdkPLNdXtNbPr6yV9OeuNkBDAdKe+0WJlq2FGBPgBmbsqP7PBJ4ArQmjASaW QM1CjzRJ+eaJa1Q5gmo9gzFRPf66SZslFk7N1hRM+dyOwmh8+lBNOtkTjNoFqAlL6e 7FkG7cNkolMei0ZHMXH0N7gp52+th5Oqp+dGMQhE= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1F0463857C75 for ; Sun, 2 May 2021 14:30:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1F0463857C75 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 142EUKv3032191 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 May 2021 10:30:25 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 142EUKv3032191 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 289851E54D; Sun, 2 May 2021 10:30:20 -0400 (EDT) Subject: Re: [patch] Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb To: Jan Kratochvil References: <547bc1ec-ffa3-2705-39ca-a6d65056461d@polymtl.ca> Message-ID: Date: Sun, 2 May 2021 10:30:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sun, 2 May 2021 14:30:20 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" 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 > > * 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