Hey, Bob! On Sat, Oct 06, 2018 at 22:44:17 -0600, Bob Proulx wrote: > Let me give the discussion this way and I think you will be > convinced. :-)
Well, thanks for taking the time for such a long reply. :) > 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. 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. 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: $ perl -e 'sub foo() { foo(); }; foo()' Out of memory! $ python <<< 'def foo(): > foo() >foo()' |& tail -n1 RuntimeError: maximum recursion depth exceeded $ ruby -e 'def foo() > foo() > end > foo()' -e:2: stack level too deep (SystemStackError) Some languages I'm more familiar with: $ node -e '(function foo() { foo(); })()' [eval]:1 (function foo() { foo(); })() ^ RangeError: Maximum call stack size exceeded $ php -r 'function foo() { foo(); } foo();' Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in Command line code on line 1 $ guile -e '(let x () (+ (x)))' allocate_stack failed: Cannot allocate memory Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler. $ emacs --batch --eval '(message (defun foo () (foo)) (foo))' Lisp nesting exceeds ‘max-lisp-eval-depth’ And so on. 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. 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. 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. > This following complete C program recurses infinitely. Or at least > until the stack is exhausted. At which time it triggers a segfault > because it tries to use memory beyond the page mapped stack. [...] > Would you say that is a bug in the C language? A bug in gcc that > compiled it? A bug in the Unix/Linux kernel for memory management > that trapped the error? The parent shell that reported the exit code > of the program? Or in the program source code? I am hoping that we > will all agree that it is a bug in the program source code and not > either gcc or the kernel. :-) I agree, yes. > 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. I also agree. But the context is very different. Shell is a very, very high-level language. > This feels to me to be related to The Halting Problem. Knowing in advance whether there may be a problem certainly is, but we don't need to do that; we'd just need to detect it at runtime to provide a more useful error message. > Other shells are also fun to check: > > $ dash -c 'trap "kill 0" TERM; kill 0' > Segmentation fault > > $ ash -c 'trap "kill 0" TERM; kill 0' > Segmentation fault > > $ mksh -c 'trap "kill 0" TERM; kill 0' > Segmentation fault Heh, interesting! > $ ksh93 -c 'trap "kill 0" TERM; kill 0' > $ echo $? > 0 This is not the behavior I'd want. > $ posh -c 'trap "kill 0" TERM; kill 0' > Terminated > Terminated > Terminated > ... > Terminated > ^C :x > This finds what look like bugs in posh and ksh93. That's a fair assessment. >> it's just that most users assume that a segfault represents a >> problem with the program > > Yes. And here it indicates a bug too. It is indicating a bug in the > shell program code which sets up the infinite recursion. Programs > should avoid doing that. :-) Indeed they should, but inevitably, such bugs do happen, and mine was a particularly common pitfall: I was trying to set the variable from within a subprocess. But it wasn't in a subprocss when I originally wrote it. > The proper way for a program to terminate itself upon catching a > signal is to set the signal handler back to the default value and then > send the signal to itself so that it will be terminated as a result of > the signal and therefore the exit status will be set correctly. That's good advice. Thank you. > https://www.cons.org/cracauer/sigint.html Thanks. > Hope this helps! There was useful information, yes. I hope I was able to further clarify my concerns as well. -- Mike Gerwitz
signature.asc
Description: PGP signature