[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a recursion bug
From: |
Greg Wooledge |
Subject: |
Re: a recursion bug |
Date: |
Tue, 2 Oct 2012 13:33:17 -0400 |
User-agent: |
Mutt/1.4.2.3i |
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.
/* xmalloc.c -- safe versions of malloc and realloc */
/* Copyright (C) 1991-2009 Free Software Foundation, Inc.
This file is part of GNU Bash, the GNU Bourne Again SHell.
> Dumping core means bash lost control.
Where do you see a core dump?
- Re: a recursion bug, Linda Walsh, 2012/10/02
- Re: a recursion bug,
Greg Wooledge <=
- Re: a recursion bug, Linda Walsh, 2012/10/02
- Re: a recursion bug, Bob Proulx, 2012/10/02
- Re: a recursion bug, Steven W. Orr, 2012/10/02
- Re: a recursion bug, Linda A. Walsh, 2012/10/03
- Re: a recursion bug, Bob Proulx, 2012/10/03
- Re: a recursion bug, Greg Wooledge, 2012/10/03
- Re: a recursion bug, Chet Ramey, 2012/10/03
- Re: a recursion bug, Bob Proulx, 2012/10/03
- Re: a recursion bug, Chet Ramey, 2012/10/04
- Re: a recursion bug, Dan Douglas, 2012/10/04