From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77869 invoked by alias); 28 Mar 2019 14:39:04 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 77858 invoked by uid 89); 28 Mar 2019 14:39:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:209.85.128.68, H*RU:209.85.128.68 X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 14:38:53 +0000 Received: by mail-wm1-f68.google.com with SMTP id f3so3858436wmj.4 for ; Thu, 28 Mar 2019 07:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHETozmZ/U5CwP2D1TFyo7sjTpI4ghLYp2xGUbb8qFk=; b=sG5KeY94m40rxG8d6JtmVqOMKynL+FbC1RzYhOF5Ta8EWl2ij1LPezIvNC3JAKm70o WAFx9l7bfHfPvzeIj/bBtwPYZLlmBV0JMNE6iPOqUEjW6Hr0b26rwLX39yb4aPb2a3nK FD6b5bIQebbapPVy3dCq24+wjNvZsWF2LqBppC65IW/FiLJMgQBiODvtr52rB+eBQoV4 9JsRHBVZRh4ahVyS8ZbGqJM1/xXHoETkmCMseSErQbqnFoL0pwnwQdJ8HJAEDv0nS1ZG SCZtsbhbsJ6urLnIhHPQ8fDVhfvl0UgNdITPLq5jsQhmHmHPkFcXN3h3jwr+Kw14pHby 4kGw== MIME-Version: 1.0 References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> <87ef6vkq8a.fsf@mid.deneb.enyo.de> <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> <87bm1yho61.fsf@mid.deneb.enyo.de> <490f5b68-a9a9-943e-6485-28c0fd51835d@jguk.org> In-Reply-To: From: Jonathan Wakely Date: Thu, 28 Mar 2019 14:39:00 -0000 Message-ID: Subject: Re: Recursive SIGSEGV question To: Jonny Grant Cc: Florian Weimer , Andrew Haley , Xi Ruoyao , gcc-help Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00207.txt.bz2 On Thu, 28 Mar 2019 at 14:26, Jonny Grant wrote: > > > > On 28/03/2019 11:52, Jonathan Wakely wrote: > > On Wed, 27 Mar 2019 at 23:47, Jonny Grant wrote: > >> I did wonder, as -fsanitize=address seems to inhibit the core dump that > >> is otherwise created by the abort() that appears to be called - is that > >> a known issue? > > > > Sorry for not thinking of this before you filed the bug report, but as > > I said there, the problem is probably not Asan but your settings. > > Check what ulimit -a shows for the max core file size, see what > > 'sysctl -a | grep kernel.core' shows and if appropriate check the > > MaxCrashReportsSize in /etc/abrt/abrt.conf > > > > So Asan isn't suppressing the core file, it's just making the address > > space larger (for the shadow memory it uses to track heap usage) and > > that causes a much larger core file, which your system then doesn't > > dump. > > > > Hi! > Thank you for your reply > > My system is on unlimited core size, so should be okay, 416G free..? > > Maybe at least the code that isn't outputting the core, could output the > reason. That's not done by GCC. > I wondered if Asan had overridden the abort() function? Maybe > Asan putting in an ABRT handler...? Nope, because if that was true I wouldn't get "Aborted (core dumped)" for asan-instrumented binaries, and I do get that, unless I change settings to disallow larger core files.