Re: a recursion bug

[Linda Walsh]

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 return
> > an error condition -- like EAGAIN, ENOBUFS, ENOMEM... etc.
>
> It did fail, and it gave that message quoted up above.  (Bash isn't a
> system call, so it can't "return ENOMEM".  Those constants are only
> meaningful in the context of a C program inspecting errno, not a
> utility returning an exit status.)
>
> > Bash should catch it's own resource allocation faults and not rely on
> > something external to itself to clean up it's mess.
>
> It did.
---
        If it is catching the error in it's own code, then
why does it not return a non-zero status = to ERRNO, for the command that
caused the problem in the user shell script?


> > Dumping core means bash lost control.
>
> Where do you see a core dump?
---
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 crashing on the user's system as
coredumps are considered 'bad form'/unsightly.