From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +gnAKLKvjmAoIwAAWB0awg (envelope-from ) for ; Sun, 02 May 2021 09:57:06 -0400 Received: by simark.ca (Postfix, from userid 112) id 9A6391F11C; Sun, 2 May 2021 09:57:06 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 CC5641E783 for ; Sun, 2 May 2021 09:57:05 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5938C3857C75; Sun, 2 May 2021 13:57:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5938C3857C75 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619963825; bh=aSRJjF0H08EyT+pXZiMHbB8B1PogIVW5cpWLIVoFD9Y=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ClI7lShpVDtGFN8tHCH5LflnWMhXAa0HnDONcyuVbvsE8E1Youd8+uFaqFMkhQ66M J1Y40v3EmyDNg3C3/2P+PYJBiyiuYctNCecs0KiDnrarDs3j7eFxgFoSmhpIssRGyy 0IaCIqKVssAF3z4xreTHFPSSLaY+E4qARMR4kExM= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id ABDAB3857C75 for ; Sun, 2 May 2021 13:57:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABDAB3857C75 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-522-JWQl2YfeNJeEA5gHn7U5Zw-1; Sun, 02 May 2021 09:57:00 -0400 X-MC-Unique: JWQl2YfeNJeEA5gHn7U5Zw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7379450200; Sun, 2 May 2021 13:56:59 +0000 (UTC) Received: from host1.jankratochvil.net (unknown [10.40.192.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 86F0F19D7C; Sun, 2 May 2021 13:56:58 +0000 (UTC) Date: Sun, 2 May 2021 15:56:55 +0200 To: Simon Marchi 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: <547bc1ec-ffa3-2705-39ca-a6d65056461d@polymtl.ca> User-Agent: Mutt/2.0.6 (2021-03-06) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Jan Kratochvil via Gdb-patches Reply-To: Jan Kratochvil Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" 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). 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 . */ + +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