[debbugs-tracker] bug#13537: closed (split: memory exhausted when putting at most T/P/E bytes of lines per output file)

[GNU bug Tracking System]

Your message dated Thu, 25 Apr 2013 02:34:41 +0100
with message-id <address@hidden>
and subject line Re: bug#13537: split: memory exhausted when putting at most 
T/P/E bytes of lines per output file
has caused the debbugs.gnu.org bug report #13537,
regarding split: memory exhausted when putting at most T/P/E bytes of lines per 
output file
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
13537: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13537
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> split: memory exhausted when putting at most T/P/E bytes of lines per	output file
>
>
>
>
> Date: 
>
> Wed, 23 Jan 2013 18:58:23 -0500
>
>
>
>
> Hi All,
>
> In the `split' program of coreutils 8.20, we found a bug which is similar to the bug reported in bug#13530:
>
> Invoking `split -C T' or `split -C P' or `split -C E' will cause memory exhaustion.
>
> However, smaller units (e.g., K, M, G) work fine; bigger units (e.g., Z,
>  Y) fail properly (by outputing "invalid number of bytes").
>
> A bit dig reveals that the bug is introduced at line 1412 of split.c (coreutils 8.20):
>
> 1400: switch (split_type)
> 1401: {
>       ...
> 1411:   case type_byteslines:
> 1412:     line_bytes_split (n_units); /* this function calls xmalloc(n_bytes), which fails. */
> 1413:     break;
>       ...
>
>
>
> 1434: }
>
> `n_units' before that statement can be very large. In the case of `split -C T', it is 1099511627776.
>
> We think this is a bug similar to the one reported in bug#13530, so we bring this issue to your attention. Thanks!
>
>
> Environments:
>
> $ uname -a
> Linux anti-think 3.7.3-1-ARCH #1 SMP PREEMPT Thu Jan 17 18:52:30 CET 2013 x86_64 GNU/Linux
>
> $ pacman -Qi coreutils
> Name           : coreutils
> Version        : 8.20-1
> URL            : http://www.gnu.org/software/coreutils
> Licenses       : GPL3
> Groups         : base
> Provides       : None
> Depends On     : glibc  pam  acl  gmp  libcap
> Optional Deps  : None
> Required By    : ca-certificates  dbus  filesystem  linux  mkinitcpio  perl
>  sysvinit-tools  util-linux
> Conflicts With : None
> Replaces       : None
> Installed Size : 13820.00 KiB
> Packager       : Allan McRae <address@hidden>
> Architecture   : x86_64
> Build Date     : Wed 24 Oct 2012 03:57:11 AM EDT
> Install Date   : Sun 28 Oct 2012 01:51:06 PM EDT
> Install Reason : Explicitly installed
> Install Script : Yes
> Description    : The basic file, shell and text manipulation utilities of
> the GNU operating system
>
> CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz CPU
> memory: 4GB
>
> Best regards,
>
> -- 
> Lei Zhang
> Department of Electrical and Computer Engineering
> University of Waterloo
> 		
> 			200 University Avenue West
> 			Waterloo,
> 			Ontario,
> 			Canada
> 			N2L 3G1
> --- End Message ---

--- Begin Message --- Subject: Re: bug#13537: split: memory exhausted when putting at most T/P/E bytes of lines per output file Date: Thu, 25 Apr 2013 02:34:41 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 01/23/2013 11:58 PM, Lei Zhang wrote:
> Hi All,
> 
> In the `split' program of coreutils 8.20, we found a bug which is similar
> to the bug reported in bug#13530:
> 
> Invoking `split -C T' or `split -C P' or `split -C E' will cause memory
> exhaustion.
> 
> However, smaller units (e.g., K, M, G) work fine; bigger units (e.g., Z, Y)
> fail properly (by outputing "invalid number of bytes").
> 
> A bit dig reveals that the bug is introduced at line 1412 of split.c
> (coreutils 8.20):
> 
> 1400: switch (split_type)
> 1401: {
>       ...
> 1411:   case type_byteslines:
> 1412:     line_bytes_split (n_units); /* this function calls
> xmalloc(n_bytes), which fails. */
> 1413:     break;
>       ...
> 1434: }
> 
> `n_units' before that statement can be very large. In the case of `split -C
> T', it is 1099511627776.
> 
> We think this is a bug similar to the one reported in bug#13530, so we
> bring this issue to your attention. Thanks!

I intend to push the attached soon to fix this.

thanks,
Pádraig.

split-C-mem.patch
Description: Text Data

--- End Message ---