On Thu, Dec 17, 2015 at 2:02 AM, Chet Ramey <chet.ra...@case.edu> wrote: > On 12/14/15 2:52 AM, Piotr Grzybowski wrote: >> Hey, >> >> [..] solved the issue by --without-bash-malloc which could indicate a bug or >> lack of >> proper support in lib/malloc/malloc.c for his platform. However, we >> were unable to get more information, it is not that easy to reproduce. >> If there is no one who can reproduce this we can try again, if you >> think it is worthwhile. [..] > > I think the likely cause is that sbrk() either has a bug or is not > emulated well. I think what I said in > > http://lists.gnu.org/archive/html/bug-bash/2015-10/msg00171.html > > holds true. The likely reason that the system malloc works is that > it doesn't use sbrk().
Sounds reasonable. Then we leave it at that, unless someone wants to port malloc.c to platforms where sbrk needs to be replaced by some other system call. Proper course of action for me would be to run strace on "int main() { malloc(1024); return 1; }" to find out what call is used and introduce some #defines (perfect one: HAS_BROKEN_SBRK). sincerely, pg