public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
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>
Subject: Re: Recursive SIGSEGV question
Date: Thu, 28 Mar 2019 11:52:00 -0000	[thread overview]
Message-ID: <CAH6eHdQ2p=NPO9JY9vBudgeSL72HUgbTmOaEa2E1h8jfhWqSnQ@mail.gmail.com> (raw)
In-Reply-To: <ba3ff67f217221f0a9a2cc99b9b5816f9d784bf6.camel@mengyan1223.wang>

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.

  reply	other threads:[~2019-03-28  8:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19 22:05 Jonny Grant
2019-03-20  4:02 ` Florian Weimer
2019-03-20  8:11   ` Jonny Grant
2019-03-25 13:23   ` Jonny Grant
2019-03-25 13:27     ` Jonathan Wakely
2019-03-25 13:56     ` Florian Weimer
2019-03-25 14:01     ` Xi Ruoyao
2019-03-25 15:47       ` Florian Weimer
2019-03-25 16:10         ` Andrew Haley
2019-03-25 16:13           ` Jonny Grant
2019-03-25 16:23             ` Jonathan Wakely
2019-03-25 18:51           ` Florian Weimer
2019-03-25 20:39             ` Jonny Grant
2019-03-26  6:50               ` Xi Ruoyao
2019-03-27  0:29                 ` Jonathan Wakely
2019-03-27 21:34             ` Jonny Grant
2019-03-27 23:43               ` Jonathan Wakely
2019-03-27 23:51                 ` Jonny Grant
2019-03-28  8:26                   ` Xi Ruoyao
2019-03-28 11:52                     ` Jonathan Wakely [this message]
2019-03-29  2:24                     ` Jonny Grant
2019-03-30 17:32                       ` Jonny Grant
2023-02-19 21:21                       ` Jonny Grant
2023-02-19 21:34                         ` Jonny Grant
2019-03-28 13:55                   ` Jonathan Wakely
2019-03-28 14:39                     ` Jonny Grant
2019-03-28 14:39                       ` Jonathan Wakely
2019-03-25 20:28         ` Segher Boessenkool
2019-03-25 18:56       ` Segher Boessenkool
2019-03-25 22:05       ` Jonny Grant
2019-03-26 10:20         ` Xi Ruoyao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdQ2p=NPO9JY9vBudgeSL72HUgbTmOaEa2E1h8jfhWqSnQ@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=aph@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jg@jguk.org \
    --cc=xry111@mengyan1223.wang \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).