Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Bob Proulx Newsgroups: gnu.bash.bug Subject: Re: Segfault on recursive trap/kill Date: Mon, 8 Oct 2018 11:59:53 -0600 Lines: 149 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> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" X-Trace: usenet.stanford.edu 1539022242 19810 208.118.235.17 (8 Oct 2018 18:10:42 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Mike Gerwitz Envelope-to: bug-bash@gnu.org Mail-Followup-To: Mike Gerwitz , bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <87y3baxpy4.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 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:14704 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mike Gerwitz wrote: > Bob Proulx wrote: > > Let me give the discussion this way and I think you will be > > convinced. :-) >=20 > Well, thanks for taking the time for such a long reply. :) >=20 > > How is your example any different from a C program? Or Perl, Python, > > Ruby, and so forth? All of those also allow infinite recursion and > > the kernel will terminate them with a segfault. Because all of those > > also allow infinite recursion. A program that executes an infinite > > recursion would use infinite stack space. But real machines have a > > finite amount of stack available and therefore die when the stack is > > exceeded. >=20 > I expect this behavior when writing in C, certainly. But in languages > where the user does not deal with memory management, I'm used to a more > graceful abort when the stack gets out of control. A segfault means > something to a C hacker. It means very little to users who are > unfamiliar with the concepts that you were describing. >=20 > I don't have enough experience with Perl, Python, or Ruby to know how > they handle stack issues. But, out of interest, I gave it a try: Some of those must be maintaining the stack in program data space instead of in the machine stack space. (shrug) > $ perl -e 'sub foo() { foo(); }; foo()' > Out of memory! Perl apparently will let you use all available memory without limitation. > $ python <<< 'def foo(): > > foo() > >foo()' |& tail -n1 > RuntimeError: maximum recursion depth exceeded >... I wonder how they decide to set the depth. > $ php -r 'function foo() { foo(); } foo();' >=20 > Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to > allocate 262144 bytes) in Command line code on line 1 134M seems arbitrarily small but at least it does say exactly what it is doing there. > $ guile -e '(let x () (+ (x)))' > allocate_stack failed: Cannot allocate memory > Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind ha= ndler. >=20 > $ emacs --batch --eval '(message (defun foo () (foo)) (foo))' > Lisp nesting exceeds =E2=80=98max-lisp-eval-depth=E2=80=99 I think these two are different. It looks like guile is using libunwind to set up a stack exception handler whereas emacs appears to be using a tracked max-lisp-eval-depth variable defaulting to 800 on my system in emacs v25. This limit serves to catch infinite recursions for you before they cause actual stack overflow in C, which would be fatal for Emacs. You can safely make it considerably larger than its default value, if that proves inconveniently small. However, if you increase it too f= ar, Emacs could overflow the real C stack, and crash. > I understand that in C you usually don't manage your own stack and, > consequently, you can't say that it falls under "memory management" in > the sense of malloc(3) and brk(2) and such. But C programmers are aware > of the mechanisms behind the stack (or at least better be) and won't be > surprised when they get a segfault in this situation. >=20 > But if one of my coworkers who knows some web programming and not much > about system programming gets a segfault, that's not a friendly > error. If Bash instead said something like the above languages, then > that would be useful. >=20 > When I first saw the error, I didn't know that my trap was > recursing. My immediate reaction was "shit, I found a bug". Once I saw > it was the trap, I _assumed_ it was just exhausting the stack, but I > wanted to report it regardless, just in case; I didn't have the time to > dig deeper, and even so, I wasn't sure if it was intended behavior to > just let the kernel handle it. 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. Frankly I wasn't even aware of libunwind before this. And haven't learned enough about it to even know if that is what I should be mentioning here yet. :-) > > Shell script code is program source code. Infinite loops or infinite > > recursion are bugs in the shell script source code not the interpreter > > that is executing the code as written. >=20 > 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. :-) > > Hope this helps! >=20 > There was useful information, yes. After sifting out the non-useful information. :-) > I hope I was able to further clarify my concerns as well. You are always eloquent! :-) Bob --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEY7Fmg4Qc49wl08brQhr6Jjh/mo4FAlu7mxYACgkQQhr6Jjh/ mo5RwQ//VCBC2I4X1Th9Dn0grdgB6IcREmnvS1VjLH1NShpDfqvFdBW9+9ngNDpS PFJODA//Uz7hYofxKTNU7BL6thCxxyPEbtAMcW7TzbCWRzVJ2ebuVRU19YFwZKjH QEINQOsrvPy4hw3G2EAPfquEgWH5YFPNEopTSe47gQmc06XZVGu5XY4TRjZ/pf9T WXMBwQhVdrw/NgtzH87LR4wj+7YIE9CQ9j1n1CIWNjY5++kUGQAnR616Xf7Sm7/8 RiOwremjCsWAiUFgDFn5BspDbkD2oFGshlMFZ2h83vO3Xw6zc7pV66/f80A1fZHv D8aOzhkwgVkxfmotbKsKp5ki/2LaGat5LSwce+7bQICLO4Ts033oF0v/fYOwpeCU fq8MNmh8XHe/BqX5A8+PDd+grveDwUI/r3eqVG3tfmWPtHPiiwSQeR30PUsViuR9 JHMUst6SmObs8xvbn2m/2ksW1wyr+WHkJ6sLbuuDbg9HPovG7Q85DYKvCDlU11+u HIP5dPABN9OHPpVDeY+RY5rchqfAmvAvsrdIEylMWzsx0xRlYn4bML8C7kW7s1sv rZgSPdzmHr6d/KVY4zUvgMoH2HCl3Tqnp7CeMz7XPf8BZd5elEadNyLxiYzrWsme 98z1B/k0oWiVWQ3rXge1uiOfSI9xZ42ZkjWqK8J3X8nlmfFLhxI= =lDYa -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--