From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-63424-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 96456 invoked by alias); 28 Mar 2019 11:52:43 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-help.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 96437 invoked by uid 89); 28 Mar 2019 11:52:43 -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-Languages-Length:771, heap
X-HELO: mail-wr1-f54.google.com
Received: from mail-wr1-f54.google.com (HELO mail-wr1-f54.google.com) (209.85.221.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 11:52:41 +0000
Received: by mail-wr1-f54.google.com with SMTP id w1so22551590wrp.2        for <gcc-help@gcc.gnu.org>; Thu, 28 Mar 2019 04:52:41 -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=YFHGXePDNUENpSaSDvUX90TsldBT57kDhSIbuqjEl7c=;        b=ZgTXDuT+DY/nx4f0sSr9UUavVKhOCJ5z9eYxt0uChJEDq24EjChpCPMBbw0z2s0J+b         1StGadUvtVo2PPoyg7MlOF3GSljFdG+2Y7gATH/aI9WWd1vfEKTK2c1/Yue7LXz+9W70         1zYBQZ3a3Ur6H5Hmq69FYaD1M/KOv3plttxmij087qA1pwenL4Uyt9dWfDIFrjlsl/xJ         PI9WxstDODiAT1ffAg3aaU/ly9OIWcMb7qCZMBWxJsicbxtkZNIpFdMMS/xkPRmDxoaB         LB6MOk7OOoF8FG/rN+AQWVbOwBwkhwBXHqAY4ISrmg97mLj7aJ1Urs9yK/F67C2VAcfS         gKDA==
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> <d3e73ef74c12829b7c827434bdebd8cfe0247c60.camel@mengyan1223.wang> <87ef6vkq8a.fsf@mid.deneb.enyo.de> <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> <87bm1yho61.fsf@mid.deneb.enyo.de> <c5e1c9a6-d92f-d69e-eb97-845606b1fdf1@jguk.org> <CAH6eHdTuEb27hesYmacVNm7v0M__brk=28kxrgMQCmMxDhoeFQ@mail.gmail.com> <490f5b68-a9a9-943e-6485-28c0fd51835d@jguk.org>
In-Reply-To: <490f5b68-a9a9-943e-6485-28c0fd51835d@jguk.org>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Thu, 28 Mar 2019 13:55:00 -0000
Message-ID: <CAH6eHdQJ1L8v6BR8qRQ1WOWCF_Zwc-ckVLAO1+6s57YA-FLakA@mail.gmail.com>
Subject: Re: Recursive SIGSEGV question
To: Jonny Grant <jg@jguk.org>
Cc: Florian Weimer <fw@deneb.enyo.de>, Andrew Haley <aph@redhat.com>, 	Xi Ruoyao <xry111@mengyan1223.wang>, gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-03/txt/msg00203.txt.bz2

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.