>I'm interpreting this as an out-of-memory error as
>a result of too many file names filling up an array?
>Is that an accurate interpretation of this trace?
Nope - this problem was detected (though not necessarily
caused) in the implementation of malloc()/free() that comes
with the bash sources, which may or may not be the same
as the malloc()/free() stuff that's in the current libc.
If you have a Debian system you can do as I did:
mkdir /tmp/BASH
cd /tmp/BASH
apt-get source bash
cd bash-2.05a (or whatever)
more lib/malloc/malloc.c
This has been fun, but is starting to resemble my REAL
work, which I've been neglecting all morning. I've
reported this via the Debian bug-reporting system, BTW.
I'm not familiar with this mess but, since you asked,
here's the point in that malloc.c source file where the
decision to punt was made:
static void
internal_free (mem, file, line, flags)
PTR_T mem;
const char *file;
int line, flags;
{
register union mhead *p;
register char *ap;
register int nunits;
register unsigned int nbytes;
int ubytes; /* caller-requested size */
if ((ap = (char *)mem) == 0)
return;
p = (union mhead *) ap - 1;
if (p->mh_alloc == ISMEMALIGN)
{
ap -= p->mh_nbytes;
p = (union mhead *) ap - 1;
}
#if defined (MALLOC_TRACE) || defined (MALLOC_REGISTER)
if (malloc_trace || malloc_register)
ubytes = p->mh_nbytes;
#endif
if (p->mh_alloc != ISALLOC)
{
if (p->mh_alloc == ISFREE)
xbotch (mem, ERR_DUPFREE,
"free: called with already freed block argument", file, line);
else
xbotch (mem, ERR_UNALLOC,
"free: called with unallocated block argument", file, line);
}
ASSERT (p->mh_magic2 == MAGIC2);
nunits = p->mh_index;
nbytes = ALLOCATED_BYTES(p->mh_nbytes);
/* Since the sizeof(u_bits32_t) bytes before the memory handed to the user
are now used for the number of bytes allocated, a simple check of
mh_magic2 is no longer sufficient to catch things like p[-1] = 'x'.
We sanity-check the value of mh_nbytes against the size of the blocks
in the appropriate bucket before we use it. This can still cause problems
and obscure errors if mh_nbytes is wrong but still within range; the
checks against MAGIC1 will probably fail then. Using MALLOC_REGISTER
will help here, since it saves the original number of bytes requested. */
if (IN_BUCKET(nbytes, nunits) == 0)
xbotch (mem, ERR_UNDERFLOW,
"free: underflow detected; mh_nbytes out of range", file, line);
.
.
.
.
.
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
