From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-63423-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 98011 invoked by alias); 28 Mar 2019 08:26:01 -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 97995 invoked by uid 89); 28 Mar 2019 08:26:01 -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=crashed, HX-Languages-Length:729
X-HELO: mail-wm1-f47.google.com
Received: from mail-wm1-f47.google.com (HELO mail-wm1-f47.google.com) (209.85.128.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 08:26:00 +0000
Received: by mail-wm1-f47.google.com with SMTP id n25so111599wmk.4        for <gcc-help@gcc.gnu.org>; Thu, 28 Mar 2019 01:25:59 -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=dH0vlm97tUrjSce6Z9X0bk4dA7BXry27vmSiTosYg7M=;        b=F9UlRo2RVk5EWCdzbJBFHwiyTqJDcbtXrIjU+nq0ZfqOpYmOlWa0MVM/hVe3AUVW4D         2RsM8dThezyol1yIOjlaqlx6cqgP68rgtlvZjEosaHuP+/4SW839oyczjUNMbC5Jqjjw         QSDx6VFYvFP1XAf4w/JUk0twtVlLEbeanwRd6ssvRSy2cYzGrn5hiDe1W5DON11VBAIR         EYQQNuZjcz0Jtm9Tns35egitWGB+3W1nKo5QfDMx/dFDeJAQuY4DwoshbR5AHDd4d1zB         kTJJhTHsa3JxGhwvCNVlrqp2222MtIgnn+9JpanFkdGP+31j2b5upRNNPwVcPOOeiDb7         qyCQ==
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> <ba3ff67f217221f0a9a2cc99b9b5816f9d784bf6.camel@mengyan1223.wang>
In-Reply-To: <ba3ff67f217221f0a9a2cc99b9b5816f9d784bf6.camel@mengyan1223.wang>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Thu, 28 Mar 2019 11:52:00 -0000
Message-ID: <CAH6eHdQ2p=NPO9JY9vBudgeSL72HUgbTmOaEa2E1h8jfhWqSnQ@mail.gmail.com>
Subject: Re: Recursive SIGSEGV question
To: Xi Ruoyao <xry111@mengyan1223.wang>
Cc: Jonny Grant <jg@jguk.org>, Florian Weimer <fw@deneb.enyo.de>, Andrew Haley <aph@redhat.com>, 	gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-03/txt/msg00202.txt.bz2

On Thu, 28 Mar 2019 at 04:59, Xi Ruoyao wrote:
> Providing backtrace with file:line requires to parse debug info.
>
> glibc libSegFault.so just record a stack bracktrace w/o line numbers.  The shell
> wrapper catchsegv convert addresses into line numbers calling addr2line.
>
> If you don't want to call addr2line (or other tools) you'll need DWARF parser in
> the executable. Why should we bloat the executable with a lot of code which
> should be in (and has been in) a debugger?

It's also a security risk to run complex parsers and other code in a
process that has just crashed due to some bug. You don't know what
state the program is in, or why it crashed, or if the stack trace is
reliable.