Re: trap recursion until SIGSEGV (non-interactive)
Thorsten Glaser t...@mirbsd.de wrote: |Steffen Nurpmeso dixit: |An interactive shell or '/usr/bin/mksh -c exec ./t.sh' limits |the storm in the same way that bash(1) does |Running 'bash t.sh' shows… | |au |au |au |after zap |au |au |au |au |au [ au] |exit |au | |… weirdly enough, but this is hardly consistent with ..consistency was what i had in mind. |the documentation of the trap builtin. And you cannot |portably catch stack underruns anyway (which is what |happens here, just like if you have a function that |recurses infinitely). I would prefer seeing a stack recursion limit exceeded or similar before SIGSEGV happens because of recursive functions, but it is possibly no good if mksh would be different. --steffen
Re: trap recursion until SIGSEGV (non-interactive)
Steffen Nurpmeso dixit: I would prefer seeing a stack recursion limit exceeded or similar before SIGSEGV happens because of recursive functions, Yeah, but I have no idea how to do that. If you find one… tell me. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Re: trap recursion until SIGSEGV (non-interactive)
Thorsten Glaser t...@mirbsd.de wrote: |Steffen Nurpmeso dixit: |I would prefer seeing a stack recursion limit exceeded or |similar before SIGSEGV happens because of recursive functions, | |Yeah, but I have no idea how to do that. If you find one… tell me. Anyway i'm thankful i was worth an answer for that -- current bash (i usually only have a stale 3.2) shows the same behaviour and after searching the web a person that ran into the same problem with bash didn't get one! And i would have said the same as someone else i saw in a different, even older message: use a recursion counter, how wacky that may be. But i guess it is not worth any effort, especially given that No. 1 changed _to_ this behaviour (even completely, exec and even interactive [but via subshell]!) and that i saw it the first time because of a bug. It's just that i am with the one that got no answer in that it didn't feel right. Just forget about it. --steffen
Re: trap recursion until SIGSEGV (non-interactive)
Steffen Nurpmeso dixit: a different, even older message: use a recursion counter, how wacky that may be. Nah. It’s either too high (with the obvious effect) or, like PHP’s, way too low (1000 just doesn’t cut it in may legitimate cases). And even a too-low one can still segfault if the user plays with ulimit -s. It's just that i am with the one that got no answer in that it didn't feel right. Just forget about it. Yeah, sorry about it. enh dixit: VMs have to deal with the more general case of this problem so they can throw whatever stack overflow exception their language defines. Hm. Not that I ever implemented even a toy VM worth note, but I’d most definitely not use the host’s stack for the VM stack, rather allocate the latter on the host heap. work out where the main thread's stack should end from /proc/maps and Ah, but that assumes there i̲s̲ a /proc/maps in the first place. surprisingly brittle, non-portable, and hard to get right though, so i'm not recommending you bother. Right. I w̲a̲s̲ wondering a bit… about a stack underflow SIGSEGV being the only one I can’t really catch… but then I remembered sigaltstack(2). Still, once I caught the SIGSEGV, what is there I can do… I guess in this case I could (after maybe setting a flag) siglongjmp to the next “up” error handler… but for that, I’d have to know that the cause of the SIGSEGV was actually a stack underflow. Or, on some platforms, stack over(!)flow. I’ve got to admit that this part of Unix is something I’m still not familiar enough with. bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;)
trap recursion until SIGSEGV (non-interactive)
Hello Thorsten, i wrote a buggy shell script similar to the crap below, but it crashed mksh(1): cat t.sh _EOT trap echo au; kill $$ TERM trap echo exit EXIT zap=`kill -TERM $$` echo after zap exit _EOT An interactive shell or '/usr/bin/mksh -c exec ./t.sh' limits the storm in the same way that bash(1) does, but running the script directly will loop until crash. (dash(1)s HEAD behaves the very same btw.) --steffen
