bug-bash
[Top][All Lists]
Advanced

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

Re: xmalloc crash


From: Chet Ramey
Subject: Re: xmalloc crash
Date: Mon, 8 Jan 2018 11:22:00 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 1/6/18 2:40 PM, Eduardo A. Bustamante López wrote:

> So the allocation fails, even if the system has enough memory to handle it.
> Upon closer inspection:
> 
>     address@hidden:~/src/gnu/bash/lib/malloc$ cat -n malloc.c | sed -n 
> '777,781p'
>        777      /* Silently reject too-large requests. */
>        778      if (nunits >= NBUCKETS) {
>        779          abort();
>        780        return ((PTR_T) NULL);
>        781      }

I'm not sure which version of bash you're looking at, since no version with
that check has ever had abort() there.

> The internal_malloc function that bash uses on some systems (instead of the
> libc provided malloc), including Linux, has a special provision that rejects
> memory requests that are too large (NBUCKETS = 30).

Because otherwise it will not run on 32-bit systems. The maximum allocation
is capped at 2**32 - 1. With the current implementation, you can run the
same binary on 32 and 64-bit systems.

When I converted the bash malloc to run on 64-bit systems (bash-2.05b) --
explicitly checking the request sizes instead of relying on 32-bit integer
overflow -- I left the maximum request size at 2*32-1 (4294967295 bytes).

You could add enough buckets to handle request sizes up to 2**63-1,
conditional on whether or not the compilation environment was for 32 or 64
bits, change NBUCKETS, add the right entries to binsizes[], and probably
have something that will handle requests larger than the current maxmimum.
I haven't done it.

> So you have two options:
> 
> (1) Compile bash by providing `--without-bash-malloc' to the `configure' 
> script
> (2) Find another option to generate all these permutations that doesn't 
> require
> requesting >580 MiB at once.

That's the wrong number.

> Question for Chet: Is there a reason we use bash-malloc in Linux systems by
> default, instead of the typical glibc malloc which is available on most of
> them?

It is 1) faster than the glibc malloc, at least when I last checked; 2)
better tuned for bash's allocation pattern; and 3) provides better
debugging info.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

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