22 ms·
Interestingly enough the lxterm I run echo `yes no` or yes `yes no` in dies after allocating somewhere around 4GB of RAM. I would expect this on a 32 or 32-pae
by Rovanion 14y ago
Interestingly enough the lxterm I run echo `yes no` or yes `yes no` in dies after allocating somewhere around 4GB of RAM. I would expect this on a 32 or 32-pae kernel but I don't understand why on a 64 bit kernel.
EDIT: Got the output by running bash in bash:
bash: xrealloc: ../bash/subst.c:5184: cannot allocate 18446744071562067968 bytes (4296822784 bytes allocated)
So now I'm wondering why 18446744071562067968 bytes is the next logical step after 4GB.
- sltkr 14y agoIt isn't -- it's just a typical 32-bit signed integer overflow that gets sign-extended to create a 64-bit unsigned integer. The previous size was probably just under 2 GB for this string. My guess is that “4296822784 bytes allocated” (which is already a little over 4 GB) refers to all the heap memory allocated so far, not just for this one string, which was actually slightly under 2 GB long. Bash is full of bugs like this; e.g. on a 64-bit system try doing echo $[263/-1].
- chrismorgan 14y ago$ bash --version GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu) ... $ echo $[263/-1] -263 What is it "supposed" (failure case) to do?
- Dylan16807 14y agoBit by HN formatting. $ echo $[2**63/-1] Floating point exception Bash crashes out entirely because it doesn't check the operands are safe. See also http://kqueue.org/blog/2012/12/31/idiv-dos/ http://kqueue.org/blog/2012/12/31/idiv-dos/
- deleted 14y ago[deleted]
- JoshuaDavid 14y ago2^32 = 4294967296 2^64 = 18446744073709551616