It's possible to grow the parameter expansion stack forever too.
$ (x=x[\${!x}]<${!x})
Segmentation fault
One would think there would be no need to keep a stack if there are no
more expansions to the right of the current expansion.
On Wed, Oct 3, 2012 at 3:39 PM, Chet Ramey wrote:
> On 10/3/12
On 10/3/12 5:32 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>>> Pid 4466 received a SIGSEGV for stack growth failure.
>>> Possible causes: insufficient memory or swap space,
>>> or stack size exceeded maxssiz.
>>
>> There's not actually anything you can do about that except use ulimit to
>> get as mu
Chet Ramey wrote:
> > Pid 4466 received a SIGSEGV for stack growth failure.
> > Possible causes: insufficient memory or swap space,
> > or stack size exceeded maxssiz.
>
> There's not actually anything you can do about that except use ulimit to
> get as much stack space as you can.
Well... There
Greg Wooledge wrote:
> imadev:~$ bash-4.2.28 -c 'a() { echo "$1"; a $(($1+1)); }; a 1' 2>&1 | tail
> Pid 4466 received a SIGSEGV for stack growth failure.
> Possible causes: insufficient memory or swap space,
> or stack size exceeded maxssiz.
> 6534
> 6535
> 6536
> 6537
> 6538
> 6539
> 6540
> 6541
On 10/03/2012 01:23 PM, Bob Proulx wrote:
>> But -- if it encountered an error, should it issue a SEGV and
>> coredump message, or should it terminate the wayward script/function
>> and return to the prompt?
>
> This is just the result of "Worse is Better". It is one of the
> fundamentals t
On 10/3/12 3:40 PM, Greg Wooledge wrote:
> On Wed, Oct 03, 2012 at 01:23:58PM -0600, Bob Proulx wrote:
>> But in any case, is there
>> anything in there that is about bash? If so the we need an exact test
>> case.
>
> You could start with this one:
>
> imadev:~$ bash-4.2.28 -c 'a() { echo "$1";
On Wed, Oct 03, 2012 at 01:23:58PM -0600, Bob Proulx wrote:
> But in any case, is there
> anything in there that is about bash? If so the we need an exact test
> case.
You could start with this one:
imadev:~$ bash-4.2.28 -c 'a() { echo "$1"; a $(($1+1)); }; a 1' 2>&1 | tail
Pid 4466 receive
Linda A. Walsh wrote:
> Steven W. Orr wrote:
> >I think there's a fundamental misunderstanding between the
> >difference of an error code returned by a system call and the exit
> >status of a process. They're two completely different things.
>
> It's not a fundamental misunderstanding.
Steven W. Orr wrote:
I think there's a fundamental misunderstanding between the difference of
an error code returned by a system call and the exit status of a
process. They're two completely different things.
It's not a fundamental misunderstanding. It's a fundamental belief
in us
Hi,
Actually, I just change to Solaris system and running your code which still not
work.
Regards,
Yuxiang Cao
From: Yuxiang Cao
Sent: Wednesday, October 03, 2012 11:00 PM
To: Greg Wooledge
Subject: RE: a recursion bug
Hi, this is a interesting problem
On Wed, Oct 03, 2012 at 01:00:21PM +, Yuxiang Cao wrote:
> Hi, this is a interesting problem. Because My bash version is 4.1.5, so I
> simply run the similar thing as your code which give me this
> frank@frank-laptop:~/research/realfault$ bash -c 'FUNCNEST=100; a() { echo
> "$1"; a $(($1+1)
On 10/3/12 9:09 AM, Yuxiang Cao wrote:
> Hi,
> Actually, I just change to Solaris system and running your code which still
> not work.
FUNCNEST is a bash-4.2 feature, which you're apparently not running.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars long
On Wed, Oct 03, 2012 at 05:07:16AM +, Yuxiang Cao wrote:
> Hi,
> After second thought, I carefully read the bash manual page and find this
> information. Functions may be recursive. The FUNCNEST variable may be used to
> limit the depth of the function call stack and restrict the number of
> fu
__
From: Linda Walsh [b...@tlinx.org]
Sent: Wednesday, October 03, 2012 3:01 AM
To: chet.ra...@case.edu
Cc: Yuxiang Cao; bug-bash@gnu.org
Subject: Re: a recursion bug
Chet Ramey wrote:
> On 9/28/12 9:54 AM, Yuxiang Cao wrote:
>> I use ulimit -s to find stack size, which i
On 10/02/12 14:03, quoth Linda Walsh:
Greg Wooledge wrote:
I see a system message from the original posters program:
Segmentation fault (core dumped)
Finding it is left as an exercise to the reader.
It is noted that many programs catch fatal signals in order
to not leave evidence of their
Linda Walsh wrote:
> Greg Wooledge wrote:
> >Linda Walsh wrote:
> >>>Yuxiang Cao wrote:
> test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate
> 172 bytes (8359936 bytes allocated)
> >
> >>Why shouldn't bash fail at the point it hits resource exhaustion and return
> >>an error condi
Yuxiang Cao wrote:
> I use ulimit -s to find stack size, which is 8192kbytes. Then I use
> valgrind to record the stack size which give me this information.
> test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
> (8359936 bytes allocated)
> So from the above information I think
Greg Wooledge wrote:
On Tue, Oct 02, 2012 at 10:01:43AM -0700, Linda Walsh wrote:
On 9/28/12 9:54 AM, Yuxiang Cao wrote:
test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
(8359936 bytes allocated)
Why shouldn't bash fail at the point it hits resource exhaustion and ret
On Tue, Oct 02, 2012 at 10:01:43AM -0700, Linda Walsh wrote:
> >On 9/28/12 9:54 AM, Yuxiang Cao wrote:
> >>test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
> >>(8359936 bytes allocated)
> Why shouldn't bash fail at the point it hits resource exhaustion and return
> an error
Chet Ramey wrote:
On 9/28/12 9:54 AM, Yuxiang Cao wrote:
I use ulimit -s to find stack size, which is 8192kbytes. Then I use
valgrind to record the stack size which give me this information.
test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes (8359936
bytes allocated
On 9/28/12 9:54 AM, Yuxiang Cao wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_V$
> un
21 matches
Mail list logo
