Bug#788979: dash: "Argument list too long" error on not too long argument
On Sat, Aug 15, 2015 at 02:13:22AM +0200, Vincent Lefevre wrote:
> On 2015-08-14 20:16:27 +0200, Jilles Tjoelker wrote:
> > This is not a bug in dash but either in the Linux kernel or in glibc.
> > The existence of MAX_ARG_STRLEN (see execve(2)) could be considered a
> > bug, since POSIX does not provide a hint that a limit on the length of
> > an individual argument may exist.
> Actually such a limitation seems to be allowed by POSIX:
> [E2BIG]
> Argument list too long. The sum of the number of bytes used by
> the new process image's argument list and environment list is
> greater than the system-imposed limit of {ARG_MAX} bytes.
> or:
> Lack of space in an output buffer.
> or:
> Argument is greater than the system-imposed maximum.
> This is the third case, but then, the error message is incorrect
> ("Argument list too long" corresponds to the first case). A glibc
> bug in this case? There's the same message with bash and zsh.
I think that condition is intended for different functions, since it is
mentioned in XSH 2.3 Error Numbers and not in the exec page in XSH 3
System Interfaces.
Although POSIX allows implementation-specific error conditions, they may
be a bad idea because they hinder portability.
> > However, it seems unlikely that this bug will be fixed given that it
> > has existed for so long already and was deliberately introduced.
> Perhaps it made sense 10 years ago, but nowadays this limit is
> rather ridiculous (makes me think of Microsoft's 640 KB limit).
I think this was that kind of limit, yes, although it introduced
dependency on gmake smarts years ago (in Linux, it's common for UTILITY
MANY_ARGS to be acceptable but sh -c 'UTILITY MANY_ARGS' to fail with
[E2BIG]).
> > Alternatively, the bug is an incorrect return value from
> > sysconf(_SC_ARG_MAX). Given the existence of MAX_ARG_STRLEN, the value
> > returned should never be more than MAX_ARG_STRLEN (131072 on most
> > architectures), since that is the longest total length of arguments that
> > is guaranteed to avoid [E2BIG] errors.
> Since POSIX allows such a system limit in addition to the total
> size, I'd say that the sysconf value is correct, but the error
> message is not the correct one (see above).
> > The [E2BIG] from "/bin/true" by itself seems strange and does not match
> > the bug's descriptive text.
> This problem seems to be specific to dash.
In interactive mode outside functions, dash sets the variable _ to the
last argument after executing a simple command, but normally does not
export it. Both bash and zsh export the variable, though, so when dash
is started from bash or zsh, each command gets the last argument of the
previous command in its environment. This may cause [E2BIG] errors.
Bash and zsh set _ before running the command, so the program gets its
own last argument and it is unlikely [E2BIG] will occur that would not
have occurred without _.
--
Jilles Tjoelker
Bug#788979: dash: "Argument list too long" error on not too long argument
On 2015-08-14 20:16:27 +0200, Jilles Tjoelker wrote:
> This is not a bug in dash but either in the Linux kernel or in glibc.
>
> The existence of MAX_ARG_STRLEN (see execve(2)) could be considered a
> bug, since POSIX does not provide a hint that a limit on the length of
> an individual argument may exist.
Actually such a limitation seems to be allowed by POSIX:
[E2BIG]
Argument list too long. The sum of the number of bytes used by
the new process image's argument list and environment list is
greater than the system-imposed limit of {ARG_MAX} bytes.
or:
Lack of space in an output buffer.
or:
Argument is greater than the system-imposed maximum.
This is the third case, but then, the error message is incorrect
("Argument list too long" corresponds to the first case). A glibc
bug in this case? There's the same message with bash and zsh.
> However, it seems unlikely that this bug will be fixed given that it
> has existed for so long already and was deliberately introduced.
Perhaps it made sense 10 years ago, but nowadays this limit is
rather ridiculous (makes me think of Microsoft's 640 KB limit).
> Alternatively, the bug is an incorrect return value from
> sysconf(_SC_ARG_MAX). Given the existence of MAX_ARG_STRLEN, the value
> returned should never be more than MAX_ARG_STRLEN (131072 on most
> architectures), since that is the longest total length of arguments that
> is guaranteed to avoid [E2BIG] errors.
Since POSIX allows such a system limit in addition to the total
size, I'd say that the sysconf value is correct, but the error
message is not the correct one (see above).
> The [E2BIG] from "/bin/true" by itself seems strange and does not match
> the bug's descriptive text.
This problem seems to be specific to dash.
--
Vincent Lefèvre - Web:
Bug#788979: dash: "Argument list too long" error on not too long argument
Package: dash Version: 0.5.7-4+b1 Severity: important $ getconf ARG_MAX 2097152 $ seq 3 | wc -c 168894 $ /bin/true "`seq 3`" sh: 3: /bin/true: Argument list too long $ /bin/true sh: 4: getconf: Argument list too long $ With a limit of 2 MB, I should have never got this error. This is a serious limitation of dash, which prevents one from opening not very large data with Firefox, where the "data:" URI is the recommended solution. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dash depends on: ii debianutils 4.5.1 ii dpkg 1.18.1 ii libc62.19-18 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
