Summary: | app-shells/bash will `read` data forever if no newline is found | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gordon Malm (RETIRED) <gengor> |
Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | jamesb.fe80, kfm, zorry |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Gordon Malm (RETIRED)
![]() Appears similar to: https://lists.ubuntu.com/archives/hardy-changes/2008-May/011496.html However, it was supposedly fixed in bash-3.2.38, so don't know what to make of that. > foo.txt:
> dd if=/dev/zero of=/dev/null bs=1M count=10
> (or pick your favorite way to make this file)
I apologize, that should've obviously read:
foo.txt:
dd if=/dev/zero of=foo.txt bs=1M count=10
(or pick your favorite way to make a 10MB or larger file)
I've tinkered with this a little on my Kubuntu laptop, and mistakenly concluded it was fixed there. After repetitive tinkering, I have concluded that (for mine) a limit setting of less than 43476 produces the following output. Which may or may not be related.
>foo2.sh: xrealloc: ../../bash/builtins/../../bash/builtins/read.def:444: cannot reallocate 8388720 bytes (0 bytes allocated)
>FAIL
stuff
I built bash 4.0.0 from source on my laptop, and It exhibits an additional behaviors, with modified version of foo.sh values of 43472 and over pass. values of 10143 and under segfault. values between usually fail producing output like: >bash: xrealloc: ../bash/general.c:888: cannot reallocate 262144 bytes (0 bytes allocated) sometimes I got other results such as the following three. >foo2.sh: xrealloc: ../../bash/builtins/../../bash/builtins/read.def:444: cannot reallocate 524400 bytes (0 bytes allocated) >bash: error while loading shared libraries: libdl.so.2: failed to map segment from shared object: Cannot allocate memory >bash: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory Ignore the previous comment, it was valid if bash4 was running the outer script and bash3 the inner. the following is slightly more relevant junk. 4.0_p17-r1 (w/ 'examples net nls' on my Hardened Funtoo): FAIL To succeed that version needs 14900 in the ulimit line. I don't suppose bash could be mmap'ing the file and then using lot's of overhead to run the scripts? I'd think that a better test would be to run a test w/ multiple discrete parts each requiring a set amount of memory, and see it the suite require significantly more vm than the individual tests. /me exposes ignorance and stupidity. Tested more recent version on x86-32 compiled with gcc-3.4.6-r2 and gcc-4.3.4. app-shells/bash-4.0_p28: FAIL i dont think this is a bug. you're giving bash a large stream of characters without any newlines. `read` requires a newline to stop its reading. as such, bash continues to read in from your "endless" stream until whatever arbitrary limit you set is hit. simpler example: cat /dev/zero | { read v ; } then in another shell, do: while sleep 1s; do clear; ps auxOR | grep bash | tail -n1 ; done |