Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14705

Re: Segfault on recursive trap/kill

From Mike Gerwitz <mtg@gnu.org>
Newsgroups gnu.bash.bug
Subject Re: Segfault on recursive trap/kill
Date 2018-10-08 21:05 -0400
Message-ID <mailman.1894.1539047182.1284.bug-bash@gnu.org> (permalink)
References (1 earlier) <25389056-9fcf-1d31-36d8-13098769a43a@case.edu> <874ldy1vka.fsf@gnu.org> <20181006210450465282080@bob.proulx.com> <87y3baxpy4.fsf@gnu.org> <20181008113728196761334@bob.proulx.com>

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Mon, Oct 08, 2018 at 11:59:53 -0600, Bob Proulx wrote:
> Some of those must be maintaining the stack in program data space
> instead of in the machine stack space.  (shrug)

Indeed.  But as I mentioned in another comment, such an implementation
detail shouldn't matter to the user IMO.

> My interpretation of the above is that you would want bash to use
> libunwind (or whatever is appropriate) to set up a stack overflow
> exception trap in order to handle stack overflow specially and then to
> make an improved error reporting to the user when it happens.

Either handle SIGSEGV and output a user-friendly message or do something
like FUNCNEST does today.  libunwind wouldn't be necessary, but I
don't know enough about it to say whether or not it may be useful.

But seeing as how the segfault isn't a bug after all (I'd consider it a
lack of a feature to provide the user with a more useful message), I'm
no longer concerned.  But if someone _is_ interested in providing an
improvement, I think it'd be a good one to have.  I unfortunately am
stretched far too thin to work on a patch.

>> I also agree.  But the context is very different.  Shell is a very,
>> very high-level language.
>
> My mind reels at the statement, "Shell is a very, very high-level
> language."  What?!  The shell is a very simple low level command and
> control language.  It is very good at what it does.  But if one needs
> to do high level things then one should switch over to a high level
> language. :-)

I mean "high level" in the sense that machine code is low-level, x86
assembly is somewhat high-level (because it was designed for use by a
programmer and includes many conveniences for doing so), C is
high-level, Perl/Python/etc are very high-level, and Bash is so
high-level that you're dealing with process manipulation---something
very far abstracted from how a computer actually works.

So, high-level in the sense of:
  https://en.wikipedia.org/wiki/High-level_programming_language

> After sifting out the non-useful information.  :-)

That information was useful information regardless of whether I was
aware of it. :)  I'm sure I'm not the only person who read your message.

> You are always eloquent! :-)

You as well!

-- 
Mike Gerwitz

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: Segfault on recursive trap/kill Mike Gerwitz <mtg@gnu.org> - 2018-10-08 21:05 -0400

csiph-web