From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43386 invoked by alias); 28 Mar 2019 14:26:16 -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 43367 invoked by uid 89); 28 Mar 2019 14:26:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=realtime, real-time, seg, H*M:6b7c X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 14:26:14 +0000 Received: by mail-wm1-f65.google.com with SMTP id q16so3796555wmj.3 for ; Thu, 28 Mar 2019 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NOtSdSa4btwEsYfUGws9/9rrutxkZZzlyIAL1VqCywQ=; b=k8gOpa4kumcI66L9NX1i7AsCK9Di6OB1hsvFWEAfEEVY/sm/MKYxdcrvHnT2ibWEbj ZgA0btwhwtoTCpMCJCTe/zebevpKsdlQBxlUBKfG0pTJQ8wZsLH+5L5lkEnepEHBWy4m iBZPSmVWCiUXDoDzh7QMAQ+BcVnTK0Df+JkVNA5BcAD1O6U/JAVq2FI67z+T93OF4vt1 2mSgqcTgB3Y3HaM9gLrG/VcC/y5YyFEHSpQh4nVmtaTePipy+xD88OLTuWo4ZBkDZYaT elxxAA0Hlxot/S66UL2liP4jKQvggTlg9yJnHI/tPOXGC2LGs5Xh71FLIvv8dmuXeZnQ HkGA== Return-Path: Received: from [192.168.1.71] (251.98.189.80.dyn.plus.net. [80.189.98.251]) by smtp.gmail.com with ESMTPSA id u14sm2677311wrr.1.2019.03.28.07.26.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 07:26:11 -0700 (PDT) Subject: Re: Recursive SIGSEGV question To: Jonathan Wakely Cc: Florian Weimer , Andrew Haley , Xi Ruoyao , gcc-help 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> From: Jonny Grant Message-ID: Date: Thu, 28 Mar 2019 14:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00206.txt.bz2 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. I wondered if Asan had overridden the abort() function? Maybe Asan putting in an ABRT handler...? It would b the same as sending ABRT signal I expect: kill -ABRT $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63536 max locked memory (kbytes, -l) 16384 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63536 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # sysctl -a | grep kernel.core kernel.core_pattern = core kernel.core_pipe_limit = 0 kernel.core_uses_pid = 0 sysctl: reading key "net.ipv6.conf.all.stable_secret" sysctl: reading key "net.ipv6.conf.default.stable_secret" sysctl: reading key "net.ipv6.conf.enp4s0.stable_secret" sysctl: reading key "net.ipv6.conf.lo.stable_secret" sysctl: reading key "net.ipv6.conf.vmnet1.stable_secret" sysctl: reading key "net.ipv6.conf.vmnet8.stable_secret" sysctl: reading key "net.ipv6.conf.wlp3s0.stable_secret" I don't have /etc/abrt/abrt.conf on Ubuntu Jonny