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.