Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14705
| 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> |
[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
Re: Segfault on recursive trap/kill Mike Gerwitz <mtg@gnu.org> - 2018-10-08 21:05 -0400
csiph-web