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

Groups > gnu.bash.bug > #14705 > unrolled thread

Re: Segfault on recursive trap/kill

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

#14705 — Re: Segfault on recursive trap/kill

[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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web