seems like this release is in a pretty bad state? github CI is failing for
both linux and macOS... linux seems to have some tar failures
FAIL: tar sparse without overflow
echo -ne '' | tar c --owner root --group sys --mtime @1234567890 --sparse
fweep | SUM 3
--- expected 2023-07-29 01:27:20.471064281 +0000
+++ actual 2023-07-29 01:27:20.475064343 +0000
@@ -1 +1 @@
-50dc56c3c7eed163f0f37c0cfc2562852a612ad0
+4b0cf135987e8330d8a62433471faddccfabac75
FAIL: tar sparse single overflow
echo -ne '' | tar c --owner root --group sys --mtime @1234567890 --sparse
fweep | SUM 6
--- expected 2023-07-29 01:27:20.503064777 +0000
+++ actual 2023-07-29 01:27:20.507064839 +0000
@@ -1 +1 @@
-81d59c3a7470201f92d60e63a43318ddde893f6d
+c5740776796acab521533a1e670f7a649da8f38c
FAIL: tar sparse double overflow
echo -ne '' | tar c --owner root --group sys --mtime @1234567890 --sparse
fweep | SUM 7
--- expected 2023-07-29 01:27:20.719068123 +0000
+++ actual 2023-07-29 01:27:20.723068185 +0000
@@ -1 +1 @@
-024aacd955e45f89bafedb3f37c8d39b4d556471
+0b5378461af0fd246453f033ef982004bc3568a6
FAIL: tar sparse extract
echo -ne '' | tar xf fweep.tar && tar c --owner root --group sys --mtime
@1234567890 --sparse fweep | SUM 4
--- expected 2023-07-29 01:27:20.731068309 +0000
+++ actual 2023-07-29 01:27:20.743068495 +0000
@@ -1 +1 @@
-b949d3a3b4c6457c873f1ea9918fd9029c5ed4b3
+7c745aba4e588eccd70373358b74e5c1be3f4f6c
PASS: tar sparse tvf
FAIL: tar sparse extract hole at end
echo -ne '' | tar xf fweep2.tar && tar c --owner root --group sys --mtime
@1234567890 --sparse fweep2 | SUM 4
--- expected 2023-07-29 01:27:20.755068681 +0000
+++ actual 2023-07-29 01:27:20.763068805 +0000
@@ -1 +1 @@
-807664bcad0e827793318ff742991d6f006b2127
+14e4e8a41b74ed87d5de37f2a17f5d1a5ccf00a6
and a mv failure
FAIL: mv random file to new file
echo -ne '' | mv file1 file2 && [ ! -e file1 -a -f file2 ] && stat -c %s
file2
--- expected 2023-07-29 01:27:12.202935388 +0000
+++ actual 2023-07-29 01:27:12.206935451 +0000
@@ -1 +1 @@
-5243392
+10752
though the latter might be flaky?
i tried to reproduce locally, but hit a few different asan failures. linux
has an asan failure in blkid (patch sent already) and macOS dies in the id
0 test:
==30338==ERROR: AddressSanitizer: heap-use-after-free on address
0x0001067030d0 at pc 0x0001034c5d54 bp 0x00016ce6a960 sp 0x00016ce6a110
READ of size 5 at 0x0001067030d0 thread T0
#0 0x1034c5d50 in wrap_strdup+0x14c
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3dd50) (BuildId:
f0a7ac5c49bc3abc851181b6f92b308a32000000200000000100000000000b00)
#1 0x18522fbf0 in xpc_string_create+0x10 (libxpc.dylib:arm64e+0x1bf0)
(BuildId: 33177e909bb236c59b6021cbca32bb7032000000200000000100000000050d00)
#2 0x18522fba4 in xpc_dictionary_set_string+0x20
(libxpc.dylib:arm64e+0x1ba4) (BuildId:
33177e909bb236c59b6021cbca32bb7032000000200000000100000000050d00)
#3 0x1855376e0 in ds_grouplist+0x114
(libsystem_info.dylib:arm64e+0xd6e0) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#4 0x1855375a8 in search_groupist+0x6c
(libsystem_info.dylib:arm64e+0xd5a8) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#5 0x185537480 in getgrouplist_internal+0x74
(libsystem_info.dylib:arm64e+0xd480) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#6 0x102fe6b20 in do_id id.c:113
#7 0x102fe679c in id_main id.c:167
#8 0x102faf0ec in toy_exec_which main.c:229
#9 0x102fadca8 in toybox_main main.c:255
#10 0x102faf2ac in main main.c:302
#11 0x18519ff24 (<unknown module>)
0x0001067030d0 is located 112 bytes inside of 159-byte region
[0x000106703060,0x0001067030ff)
freed by thread T0 here:
#0 0x1034cafa4 in wrap_free+0x98
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x42fa4) (BuildId:
f0a7ac5c49bc3abc851181b6f92b308a32000000200000000100000000000b00)
#1 0x18552e774 in LI_set_thread_item+0x24
(libsystem_info.dylib:arm64e+0x4774) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#2 0x18552c314 in getpwuid+0x78 (libsystem_info.dylib:arm64e+0x2314)
(BuildId: 4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#3 0x1034aabb8 in wrap_getpwuid+0x5c
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x22bb8) (BuildId:
f0a7ac5c49bc3abc851181b6f92b308a32000000200000000100000000000b00)
#4 0x102fab658 in xgetpwuid xwrap.c:715
#5 0x102fe6a34 in do_id id.c:107
#6 0x102fe679c in id_main id.c:167
#7 0x102faf0ec in toy_exec_which main.c:229
#8 0x102fadca8 in toybox_main main.c:255
#9 0x102faf2ac in main main.c:302
#10 0x18519ff24 (<unknown module>)
previously allocated by thread T0 here:
#0 0x1034cae68 in wrap_malloc+0x94
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x42e68) (BuildId:
f0a7ac5c49bc3abc851181b6f92b308a32000000200000000100000000000b00)
#1 0x18552df80 in LI_ils_create+0x470
(libsystem_info.dylib:arm64e+0x3f80) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#2 0x185532da0 in _fsi_get_user+0x228
(libsystem_info.dylib:arm64e+0x8da0) (BuildId:
4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#3 0x18552c2d8 in getpwuid+0x3c (libsystem_info.dylib:arm64e+0x22d8)
(BuildId: 4cc3e383c5483975b46449e2ee7dcf4e32000000200000000100000000050d00)
#4 0x1034aabb8 in wrap_getpwuid+0x5c
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x22bb8) (BuildId:
f0a7ac5c49bc3abc851181b6f92b308a32000000200000000100000000000b00)
#5 0x102fe694c in do_id id.c:99
#6 0x102fe679c in id_main id.c:167
#7 0x102faf0ec in toy_exec_which main.c:229
#8 0x102fadca8 in toybox_main main.c:255
#9 0x102faf2ac in main main.c:302
#10 0x18519ff24 (<unknown module>)
looks like a classic "the passwd functions don't guarantee the lifetime of
a result past another call to a passwd function" issue?
linux also dies in the sed timeout test; that seems to be a pathological
case for asan because increasing the timeout to 60s also didn't pass.
(though weirdly, that test is fine -- finishing almost instantly, just like
non-asan -- on macOS. not sure whether that's a bsd/glibc difference or a
linux-only asan bug. the latter seems less likely, but i'll mention it to
the asan folks anyway...)
i *couldn't* reproduce the tar failures locally (the failure at the top was
copy & pasted from github ci results), so maybe another lurking fs
dependency?
On Sun, Jul 30, 2023 at 1:32 PM Rob Landley <r...@landley.net> wrote:
> I was _trying_ not to call in that (sorts terribly in the directory
> listing) but
> I have goals for 0.9.0 I didn't achieve yet (test suite running under
> mkroot,
> and maybe a basic LFS build too albeit starting out with a pile of
> supplementary
> binaries). And after stretching the dev cycle out to TWICE normal release
> length... I just did an 0.8.10 release.
>
> In addition to the zillions of bugfixes and new command --flags, "dd"
> finally
> got cleaned up and promoted, and a BUNCH of upgrades to mkroot. Shell's
> still in
> flux and I need to get back to that this week. (The release happened by NOT
> finishing and merging a bunch of pending work. Didn't check in the
> /etc/passwd
> plumbing rewrite, didn't check in the fixes to make cp -s more robust like
> readlink/realpath...)
>
> I also hope to get https://landley.net/talks/mkroot-2023.txt actually
> recorded
> soonish.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
