On 08/28/2014 03:50 PM, bogun.dmit...@gmail.com wrote: > Any action in my script should lead to SIGSEGV in interpreter! If I write > program on some compilable language, for example C, compile it and got > SIGSEGV - this is my problem. But in this case, my program executed by > interpreter, and if interpreter fail, despite reasons, this is problem of > interpreter.
No, it is a problem of your buggy program. > > What you will say if gcc(cc) will down with SIGSEGV while compiling your > code? Is it problem of gcc or your code? If gcc segfaults because it implements #include via recursion, and I wrote a recursion loop of #includes into my source, then I'd say the bug was mine, not gcc's. Just the same as if you write a recursion loop into your bash program. It's not the compiler's fault that input that requests recursion can abuse the stack. Rather, it is the fault of the input. > To be short - you(community) don't want to add limit, because its default > value shoul be infinite! I'm not saying that a limit is a bad idea, just that a limit on by default is a bad idea (it goes against the GNU Coding Standards of no arbitrary limits). The moment YOU change from the default of unlimited to your chosen limit, it is no longer an arbitrary limitation of bash, but a conscious choice on your part. But as long as the limit defaults to being off, it brings us back to the question of whether bash should dump core when the stack overflows due to a buggy user input. It's not a bug in bash, but in the user program; and that's WHY libsigsegv exists (to convert what would have been a core dump into a nice error message, making it obvious that the bug was in the user input). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
