[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a recursion bug

From: Linda Walsh
Subject: Re: a recursion bug
Date: Tue, 02 Oct 2012 11:03:14 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]