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
Mike Gerwitz wrote:
> 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
On Sun, Oct 07, 2018 at 09:42:01 +0700, Robert Elz wrote:
> I expect that if you did look, you'd probably find that while
> technically the former, it isn't a reference to some wild pointer,
> but rather simply growing the stack until the OS says "no more"
> and returns a SIGSEGV instead af
On Sun, Oct 07, 2018 at 08:52:25 +0200, Valentin Bajrami wrote:
> As earlier expained, you are calling foo function recursively. To mitigate
> this behaviour you simple set FUNCNEST= foo() { foo; }; foo where N
> denotes the number of nested functios to be called.
This is perfect and clear
Hi Mike,
As earlier expained, you are calling foo function recursively. To mitigate
this behaviour you simple set FUNCNEST= foo() { foo; }; foo where N
denotes the number of nested functios to be called.
Op zo 7 okt. 2018 07:57 schreef Mike Gerwitz :
> Hey, Bob!
>
> On Sat, Oct 06, 2018 at
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
Hi Mike,
Mike Gerwitz wrote:
> ... but are you saying that terminating with a segfault is the
> intended behavior for runaway recursion?
Let me give the discussion this way and I think you will be
convinced. :-)
How is your example any different from a C program? Or Perl, Python,
Ruby, and so
Date:Sat, 06 Oct 2018 19:53:25 -0400
From:Mike Gerwitz
Message-ID: <874ldy1vka@gnu.org>
| I haven't inspected the code to see if this is an access
| violation or if Bash is intentionally signaling SIGSEGV.
I expect that if you did look, you'd probably find
On Sat, Oct 06, 2018 at 12:33:22 -0400, Chet Ramey wrote:
> On 10/5/18 9:33 PM, Mike Gerwitz wrote:
>> The following code will cause a segfault on bash-4.4.19(1) on
>> GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
>> bash-4.3.11(1) as well as a Trisquel system running the
On 10/5/18 9:33 PM, Mike Gerwitz wrote:
> The following code will cause a segfault on bash-4.4.19(1) on
> GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
> bash-4.3.11(1) as well as a Trisquel system running the same version.
>
> bash -c 'trap "kill 0" TERM; kill 0'
>
>
The following code will cause a segfault on bash-4.4.19(1) on
GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
bash-4.3.11(1) as well as a Trisquel system running the same version.
bash -c 'trap "kill 0" TERM; kill 0'
Also segfaults when replacing `0' with `$$', and
11 matches
Mail list logo
