[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:
>
> dualbus@ubuntu:~/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 chet@case.edu http://tiswww.cwru.edu/~chet/