Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Control: retitle -1 general: on hppa, command line of any program invocation is
limited to less than 3544 bytes
Control: severity -1 wishlist
On Tue, 21 Nov 2023 at 17:26:46 +0100, Bruno Haible wrote:
> I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU
> 8.0.2.
hppa is a "ports" architecture, which is maintained by its port
maintainers but not supported by the Debian project as a whole. Debian 6.0
was the last release where hppa was supported as a release architecture,
and reached EOL in early 2012.
Full text quoted below for the hppa porters (cc'd).
/bin/echo `seq 913` seems to work on both 32-bit and 64-bit release
architectures (tested 32-bit armhf on the porterbox "abel" and 64-bit
amd64 on my laptop) so this appears to be an architecture-specific
problem, presumably caused by either different configuration,
architecture-specific code paths, or the version of some component being
out of date on hppa.
> $ uname -srm
> Linux 6.3.0-2-parisc parisc
>
> In this machine, for the invocation of any program, the length of the command
> line (= all arguments together) is limited to less than 3544 bytes.
>
> How to reproduce:
>
> In bash:
> $ /bin/echo `seq 913`
> -bash: /bin/echo: Argument list too long
>
> In dash:
> $ /bin/echo `seq 913`
> dash: 1: /bin/echo: Argument list too long
>
> I also see this while doing "make check" of packages that have more than 1000
> tests. So, it appears to be a general problem.
>
> The values returned by getconf don't match the reality:
> $ getconf ARG_MAX
> 2097152
> $ getconf _POSIX_ARG_MAX
> 2097152
>
> I have looked at the values of several files in /sys/kernel and
> /proc/sys/kernel, without finding the cause.
>
> For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from the
> T2-SDE distribution), I don't observe this bug. Both machines have the same
> amount of "physical" RAM: 256 MiB.
>
> The ulimit values don't appear to be the cause, because they are similar in
> the two machines:
> In the Debian VM (with the bug):
> $ ulimit -a
> real-time non-blocking time (microseconds, -R) unlimited
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) unlimited
> pending signals (-i) 849
> max locked memory (kbytes, -l) 65536
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 849
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
> In the T2-SDE machine, with no bug:
> $ ulimit -a
> real-time non-blocking time (microseconds, -R) unlimited
> core file size (blocks, -c) 1048575
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) unlimited
> pending signals (-i) 909
> max locked memory (kbytes, -l) 8192
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 909
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
Reply to: