From bugzilla at busybox.net Thu Oct 6 18:18:41 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Thu, 06 Oct 2022 18:18:41 +0000
Subject: [Bug 15031] New: kbuild can't handle .config files with lines more
than 1024 lines
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15031
Bug ID: 15031
Summary: kbuild can't handle .config files with lines more than
1024 lines
Product: Busybox
Version: 1.35.x
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: slyich at gmail.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
But originally reported by brothermechanic in
https://github.com/trofi/nix-guix-gentoo/issues/22 against busybox-1.35.0.
There user's .config file contains this long line (exceeds 1K limit a bit):
> CONFIG_EXTRA_CFLAGS="-march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -dumpbase null -O2 -pipe"
That renders the following:
make oldconfig
# using defaults found in .config
#
.config:52:warning: invalid string found
.config:53:warning: unexpected data
Currently I'm woring it around bu inflating the temporary buffer:
--- busybox-1.35.0.orig/scripts/kconfig/confdata.c 2021-12-26
16:53:21.000000000 +0000
+++ busybox-1.35.0/scripts/kconfig/confdata.c 2022-10-06 18:48:01.374687000
+0100
@@ -87,7 +87,7 @@
int conf_read_simple(const char *name)
{
FILE *in = NULL;
- char line[1024];
+ char line[64 * 1024];
char *p, *p2;
struct symbol *sym;
int i;
Upstream kbuild fixed it in 2012:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a7a8c6fd8ca24d3692dacddf8d658c9bb9c14ad
Worth pulling equivalent of kernel's fix into busybox?
Thank you!
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sat Oct 8 17:45:50 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sat, 08 Oct 2022 17:45:50 +0000
Subject: [Bug 15036] New: [PATCH] Awk: fix bitwise functions when operating
with large numbers
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15036
Bug ID: 15036
Summary: [PATCH] Awk: fix bitwise functions when operating with
large numbers
Product: Busybox
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: caribpa at outlook.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
Created attachment 9376
--> https://bugs.busybox.net/attachment.cgi?id=9376&action=edit
awk-bitwiseop-fix-arch64.patch
Hi there!
While working on a small awk program in an arm64 I found that bitwise
operations are broken when operating with large numbers.
Looking under the hood I found that awk numbers are doubles[1], whereas bitwise
operations are performed over unsigned longs[2].
The problem:
- double is typically 2^53
- unsigned long is 2^32 in 32bit archs
- unsigned long is typically 2^64 in 64bit archs
So, the result of a unsigned long bitwise operation is stored on a double
This means that data is lost in 64bit archs that use 64bit unsigned longs when
the result is greater than 2^53. For example, operating with a simple compl(0)
on an arm64 or x64 Linux generates unexpected results:
awk 'BEGIN{print compl(0)%4}'
It returns 0 instead of 3.
But it works on GNU Awk, why?
Well, apparently all gawk bitwise operations return the result of a function
called make_integer[3] which in turn calls another function that fixes the
issue I described above: adjust_uint[4].
adjust_uint basically truncates sizes greater than 2^53 (like 2^64 unsigned
long) to 2^53 from the left, preserving low order bits.
So I went ahead and shamelessly copied adjust_uint into Busybox Awk and it
worked!
And here I am submitting a patch with the changes adapted to Busybox :)
This adaptation includes:
- Replacing uintmax_t with unsigned long on adjust_uint and the
count_trailing_zeros helper, as the result of bitwise operations on Busybox is
unsigned long
- Replacing GCC __builtin_ctzll (unsigned long long) with GCC __builtin_ctzl
(unsigned long)
- Including float.h for the FLT_RADIX macro
- Removing some macros that adapt adjust_uint when gawk numbers are long
doubles in some platforms
- Renaming some macros and their mention in the original gawk comments
Cheers,
Carlos
[1] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n123
[2] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n1048
[3] -
https://git.savannah.gnu.org/cgit/gawk.git/tree/builtin.c?id=d434cb3ce61e0cc5e26180da914f1a58223897a2#n3565
[4] -
https://git.savannah.gnu.org/cgit/gawk.git/tree/floatcomp.c?id=d434cb3ce61e0cc5e26180da914f1a58223897a2#n91
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sat Oct 8 18:52:16 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sat, 08 Oct 2022 18:52:16 +0000
Subject: [Bug 15041] New: [PATCH] Awk: fix printf format when using large
numbers
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15041
Bug ID: 15041
Summary: [PATCH] Awk: fix printf format when using large
numbers
Product: Busybox
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: caribpa at outlook.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
Created attachment 9381
--> https://bugs.busybox.net/attachment.cgi?id=9381&action=edit
awk-printf-fix-format-large-numbers.patch
Hi!
I noticed that Busybox awk truncates double to int when printing as %d, %i, %u,
%o, or %x [1][2]. This means that expected information is lost, for example:
awk 'BEGIN{printf "0x%x\n", 4294967290}'
returns 0x80000000 (or 0x7fffffff in some platforms) instead of 0xfffffffa,
like it happens in at least gawk, mawk, and nawk.
The patch attached simply changes the int casting into long long and removes
the TODO comment.
Cheers,
Carlos
[1] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n929
[2] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n2418
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sun Oct 9 03:06:18 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sun, 09 Oct 2022 03:06:18 +0000
Subject: [Bug 15046] New: The system hang when execute "devmem 0xfed10000
128" on NUC7
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15046
Bug ID: 15046
Summary: The system hang when execute "devmem 0xfed10000 128"
on NUC7
Product: Busybox
Version: 1.35.x
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Standard Compliance
Assignee: unassigned at busybox.net
Reporter: mingli.yu at windriver.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
root at intel-x86-64:~# devmem 0xfed10000 128
Memory mapped at address 0x7f5e5e1d5000.
The system hang
And it also hangs after execute "devmem 0xfed10000 64".
root at intel-x86-64:~# devmem 0xfed10000 64
0x0000000001C03AFE
The system hang
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sun Oct 9 03:07:56 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sun, 09 Oct 2022 03:07:56 +0000
Subject: [Bug 15046] The system hang when execute "devmem 0xfed10000 128" on
NUC7
In-Reply-To:
References:
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15046
mingli.yu at windriver.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P3
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sun Oct 9 11:54:05 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sun, 09 Oct 2022 11:54:05 +0000
Subject: [Bug 15051] New: [PATCH] Awk: fix bitwise functions result/arguments
truncation on 32bit platforms
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15051
Bug ID: 15051
Summary: [PATCH] Awk: fix bitwise functions result/arguments
truncation on 32bit platforms
Product: Busybox
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: caribpa at outlook.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
Created attachment 9386
--> https://bugs.busybox.net/attachment.cgi?id=9386&action=edit
awk-bitwise-fix-arch32.patch
Hi!
On platforms that use 32bit longs data is lost when performing bitwise
operations if the result and/or arguments are equal-to/greater-than 2^32.
This behavior is unexpected as Busybox Awk numbers are doubles[1] (typically up
to 2^53) and this issue is not present on GNU Awk.
Example 1 - Result equal-to/greater-than 2^32:
awk 'BEGIN{print lshift(1, 32)}'
It returns 1, instead of the expected 4294967296.
Example 2 - Arguments equal-to/greater-than 2^32:
awk 'BEGIN{print and(2^32, 2^32)}'
It returns 0, instead of the expected 4294967296.
The patch attached simply changes the castings and type of the getvar_i_int
function from long to long long.
Note that the patch found in bug 15036[3] adds two functions that
operate/return long numbers that shall also be changed into long long when
accepted.
Cheers,
Carlos
[1] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n123
[2] -
https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n1048
[3] - https://bugs.busybox.net/show_bug.cgi?id=15036
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Tue Oct 11 23:17:29 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Tue, 11 Oct 2022 23:17:29 +0000
Subject: [Bug 14326] [PATCH] pkill: add -e to display the name and PID of the
process being killed
In-Reply-To:
References:
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=14326
--- Comment #3 from Louis Sautier ---
(In reply to Denys Vlasenko from comment #1)
Hello Denys, did you see my previous reply?
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Thu Oct 13 23:20:27 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Thu, 13 Oct 2022 23:20:27 +0000
Subject: [Bug 15056] New: `hostname -i` fails on ipv6 hosts
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15056
Bug ID: 15056
Summary: `hostname -i` fails on ipv6 hosts
Product: Busybox
Version: 1.35.x
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Networking
Assignee: unassigned at busybox.net
Reporter: c at lvin.me
CC: busybox-cvs at busybox.net
Target Milestone: ---
Attempting to run `hostname -i` on an Alpine Linux container in an IPv6
Kubernetes installation fails to resolve the host, despite the ip and hostname
being present in /etc/hosts. On the other hand, this works in an Ubuntu
container.
Presumably this is due to the use of gethostbyname, rather than getaddrinfo.
--
You are receiving this mail because:
You are on the CC list for the bug.
From vda.linux at googlemail.com Fri Oct 14 12:33:34 2022
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 14 Oct 2022 14:33:34 +0200
Subject: [git commit] pkill: add -e to display the name and PID of the process
being killed
Message-ID: <20221014123538.35E4286C1F@busybox.osuosl.org>
commit: https://git.busybox.net/busybox/commit/?id=707a7ef4c72d1d00ff61221511a70eada19185ca
branch: https://git.busybox.net/busybox/commit/?id=refs/heads/master
This mimics the behaviour of pkill -e / --echo from procps.
function old new delta
.rodata 105179 105200 +21
packed_usage 34523 34516 -7
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 21/-7) Total: 14 bytes
Signed-off-by: Louis Sautier
Signed-off-by: Denys Vlasenko
---
procps/pgrep.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/procps/pgrep.c b/procps/pgrep.c
index 6d25c247e..82e00322f 100644
--- a/procps/pgrep.c
+++ b/procps/pgrep.c
@@ -44,7 +44,7 @@
//usage: "\n -P Match parent process ID"
//usage:
//usage:#define pkill_trivial_usage
-//usage: "[-l|-SIGNAL] [-xfvno] [-s SID|-P PPID|PATTERN]"
+//usage: "[-l|-SIGNAL] [-xfvnoe] [-s SID|-P PPID|PATTERN]"
//usage:#define pkill_full_usage "\n\n"
//usage: "Send signal to processes selected by regex PATTERN\n"
//usage: "\n -l List all signals"
@@ -55,6 +55,7 @@
//usage: "\n -v Negate the match"
//usage: "\n -n Signal the newest process only"
//usage: "\n -o Signal the oldest process only"
+//usage: "\n -e Display name and PID of the process being killed"
#include "libbb.h"
#include "xregex.h"
@@ -64,7 +65,7 @@
#define pkill (ENABLE_PKILL && (!ENABLE_PGREP || applet_name[1] == 'k'))
enum {
- /* "vlafxons:+P:+" */
+ /* "vlafxones:+P:+" */
OPTBIT_V = 0, /* must be first, we need OPT_INVERT = 0/1 */
OPTBIT_L,
OPTBIT_A,
@@ -72,6 +73,7 @@ enum {
OPTBIT_X,
OPTBIT_O,
OPTBIT_N,
+ OPTBIT_E, /* should be pkill-only, do we care? */
OPTBIT_S,
OPTBIT_P,
};
@@ -83,6 +85,7 @@ enum {
#define OPT_ANCHOR (opt & (1 << OPTBIT_X))
#define OPT_FIRST (opt & (1 << OPTBIT_O))
#define OPT_LAST (opt & (1 << OPTBIT_N))
+#define OPT_ECHO (opt & (1 << OPTBIT_E))
#define OPT_SID (opt & (1 << OPTBIT_S))
#define OPT_PPID (opt & (1 << OPTBIT_P))
@@ -93,8 +96,12 @@ static void act(unsigned pid, char *cmd, int signo)
printf("%u %s\n", pid, cmd);
else
printf("%u\n", pid);
- } else
+ } else {
kill(pid, signo);
+ if (option_mask32 & (1 << OPTBIT_E)) {
+ printf("%s killed (pid %u)\n", cmd, pid);
+ }
+ }
}
int pgrep_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
@@ -131,7 +138,7 @@ int pgrep_main(int argc UNUSED_PARAM, char **argv)
/* Parse remaining options */
ppid2match = -1;
sid2match = -1;
- opt = getopt32(argv, "vlafxons:+P:+", &sid2match, &ppid2match);
+ opt = getopt32(argv, "vlafxones:+P:+", &sid2match, &ppid2match);
argv += optind;
if (pkill && OPT_LIST) { /* -l: print the whole signal list */
From bugzilla at busybox.net Fri Oct 14 12:36:16 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Fri, 14 Oct 2022 12:36:16 +0000
Subject: [Bug 14326] [PATCH] pkill: add -e to display the name and PID of the
process being killed
In-Reply-To:
References:
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=14326
Denys Vlasenko changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Denys Vlasenko ---
Fixed in git
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Thu Oct 20 04:35:57 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Thu, 20 Oct 2022 04:35:57 +0000
Subject: [Bug 15066] New: tail with option -c fails on large files
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15066
Bug ID: 15066
Summary: tail with option -c fails on large files
Product: Busybox
Version: 1.34.x
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: kurien.mathew at mediakind.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
tail from
BusyBox v1.34.1 (2022-06-06 22:12:17 UTC) multi-call binary.
when used with the "-c +" option on a large file (several GB)
we encounter the error "tail: write error: Bad address". The error is sometimes
fatal since retries do not always help progress the offset to EOF
For eg
user at mkd:~/test$ kubectl exec -it recorder-9f955c7d4-fjqpl -c generator --
/bin/sh -c "ls -al /data/content.tar.gz"
-rw-r--r-- 1 daemon daemon 2969605492 Oct 20 00:45 /data/content.tar.gz
user at mkd:~/test$ kubectl exec recorder-9f955c7d4-fjqpl -c generator --
/usr/bin/tail -c +2963709953 /data/content.tar.gz
tail: write error: Bad address
command terminated with exit code 1
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Wed Oct 26 21:30:03 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Wed, 26 Oct 2022 21:30:03 +0000
Subject: [Bug 15076] New: nl applet missing documentation
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15076
Bug ID: 15076
Summary: nl applet missing documentation
Product: Busybox
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: laalsaas at systemli.org
CC: busybox-cvs at busybox.net
Target Milestone: ---
busybox provides the `nl` applet, for numbering lines. However, the
existance of this applet (as well as its options, if any) isn't documented at
https://www.busybox.net/downloads/BusyBox.html
, neither in the manpage.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sun Oct 30 18:49:40 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sun, 30 Oct 2022 18:49:40 +0000
Subject: [Bug 15081] New: ed bug files with few lines
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15081
Bug ID: 15081
Summary: ed bug files with few lines
Product: Busybox
Version: 1.35.x
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: ricercar at tuta.io
CC: busybox-cvs at busybox.net
Target Milestone: ---
seq 1 4 > file;busybox ed file
2i
test
.
w
q
Expect: Second line to be replaced with "test"
What happens: First line is replaced with "test"
If i use 'seq 1 6' or more instead it seems to work as expected, although I
havent tested much.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Sun Oct 30 19:27:05 2022
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sun, 30 Oct 2022 19:27:05 +0000
Subject: [Bug 15081] ed bug in files with few lines
In-Reply-To:
References:
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=15081
ricercar at tuta.io changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|ed bug files with few lines |ed bug in files with few
| |lines
--
You are receiving this mail because:
You are on the CC list for the bug.