Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Mike Gerwitz Newsgroups: gnu.bash.bug Subject: Re: Segfault on recursive trap/kill Date: Mon, 08 Oct 2018 21:05:22 -0400 Lines: 79 Approved: bug-bash@gnu.org Message-ID: References: <8736tj3llu.fsf@gnu.org> <25389056-9fcf-1d31-36d8-13098769a43a@case.edu> <874ldy1vka.fsf@gnu.org> <20181006210450465282080@bob.proulx.com> <87y3baxpy4.fsf@gnu.org> <20181008113728196761334@bob.proulx.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: usenet.stanford.edu 1539047183 2857 208.118.235.17 (9 Oct 2018 01:06:23 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org In-Reply-To: <20181008113728196761334@bob.proulx.com> (Bob Proulx's message of "Mon, 8 Oct 2018 11:59:53 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) OpenPGP: id=22175B02E626BC98D7C0C2E5F22BB8158EE30EAB X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14705 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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! =2D-=20 Mike Gerwitz --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJbu/7SAAoJEIyRe39dxRuiM8EP/1O91UvgnMH4IQm+WxPkDP9Z xAEdnO7jkDXdPSgRQHXkzop8IY5moTB51fjKKTr6hDfUQn/M3nDJaKiejg9FzwPO SDXMR2kDcK4xJb80SOZH8QJWs6TuSN1G45mLI0VDeGfazu/BSEgO1Fo/sG16eiZw bqIOl9fEd9WEZ1cqSDiuEDAsEoODd3TObpxpIuVkpqDm0uCOVYfQvuGwirHpup6d sf072E5npNvWZPjXs2pGvlQPWne+2Ev7WWQFpuf+hCwfvVyLRmC+8rFBaDk2GcCL sHkHbYRu/1HgOKY0B2QDiy8DpEzQ52drcLKJBCTygQpIn1TPO4n3oU9n0ZFJiWXo eturS/NdMVd79Q7LkMkR8psn57sCPuq9wZP2ujBo6oEcvNeOxmawQdX2Ri7fkGi9 bMKdjLQs76prU6tIdQ0yjdDY5ZgSOa3JNna6dvWUJswEtkVYCBS5lq/fSSThdO5m X0EarrHCJ81+mvgR8XeSuoD4YtEJGLGoPFn0jHW2nxM3tzLQE3XQwEhfdiRMsgY5 aEjrY3LZSH3JldwfPWPDak8UWaVbgSDAP7PREiDOWgfdv553YPgHI9QmMnFSuChL RsHfcTPzPiEQ3+fzJbDDxoENGd78gVNZmOrxGjtV3DP3PamzS361OxecydKix9nu 0q1RX3gG3sg+05Q5Edi6 =j2X7 -----END PGP SIGNATURE----- --=-=-=--