Re: a recursion bug

[Bob Proulx]

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 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.)

Careful.  That error message came from valgind not bash.  The OP ran
the program under valgrind to produce that message.

> >>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?

Note that it was *valgrind* not bash that at this point here.

> >>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)

Core dumping is disabled by default on most modern systems.  But it
may be enabled explicitly or the operating system policy may be to
enable it generally.  That is certainly outside the context of bash.

  $ ulimit -c
  0
  $ ulimit -c unlimited
  $ ulimit -c
  unlimited

You must have either enabled it explicitly or are running on a system
where dumping is globally allowed by operating system policy.  If you
don't like that then you are able to change it or to use a different
system.

> Finding it is left as an exercise to the reader.

Eureka!  I found it!  :-)

> 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.

Yes.  If I were you I would figure out why ulimit -c isn't zero for
you and then fix it.  Unless you are set up to debug the resulting
core then it isn't useful.  Also dumping a large core over the network
to an NFS mounted directory, an action that takes place in the kernel
and on at least some systems is not interruptable, a few times will
convince you that you don't want to wait for it.

Bob