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

Bug#1056357: marked as done (general: on hppa, command line of any program invocation is limited to less than 3544 bytes)

Your message dated Sun, 27 Jul 2025 17:30:28 +0200
with message-id <d6d0d84f1003fa451dbbf967a6e9a40064bc49c0.camel@decadent.org.uk>
and subject line Re: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
has caused the Debian Bug report #1056357,
regarding general: on hppa, command line of any program invocation is limited to less than 3544 bytes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1056357: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056357
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: general
Severity: important
X-Debbugs-Cc: bruno@clisp.org

I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU
8.0.2.
$ 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

--- End Message ---
--- Begin Message --- 
Version: 6.7-1~exp1

This was a regression between 6.3.7 and 6.3.11, apparently caused by
changes to the handling of stack expansion.

As Helge Deller is an hppa port maintainer for the kernel (upstream) and
Debian, I'm going to assume he's correct that this was fixed in 6.7 if
not earlier.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: