[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

execve E2BIG (Argument list too long)

From: Michael Green
Subject: execve E2BIG (Argument list too long)
Date: Wed, 30 Sep 2020 09:12:30 +0200

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux h001201355 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul
23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release


The included short script when run with the following command results
in execve "E2BIG (Argument list too long) errors".

Running "strace -f" on this shows the error, and "Argument list too
long" is printed out to stderr for the calls to external commands.

seq 1 40000 | xargs ./bash_bug

BEGIN: bash_bug
#!/usr/bin/env bash
. "exists_or_not"
export A123456789012345="${BASH_ARGV[*]}"
mkdir -p /tmp/foobar
perl -E 'say "hello world"' 'foo' 'bar'
END bash_bug

"xargs" is only used for the sake of being concise. The issue occurs
with an equivalently long list of arguments.

A number of the parameters can be tuned to make the problem occur or not.

* The number of arguments can be tuned down to "seq 1 23694" and it
still occurs, but any lower and it disappears.

* The sourcing of a file appears to be required, but it doesn't matter
what that file is or even if it exists.

* The variable name length of the exported variable must be 16 or more
characters, reducing this to 15 or less makes the bug disappear. It
also doesn't matter what characters are, any valid variable name of 16
or more characters will do.

* The path used for calling the script seems to affect the issue. In
my tests using the absolute script path sometimes made the bug
disappear, but using a local relative path seemed to reliably produce

This issue was tested on the reporting system and the oldest system I
could find and was present on both systems

* Fedora release 32 (Thirty Two) 5.7.10-201.fc32.x86_64
* Red Hat Enterprise Linux Server release 6.10 (Santiago)


Running provided script with the given command.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]