Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

[Kristof Provost]

On 14 Sep 2023, at 15:34, Mark Millard wrote:
> [I've cc'd a couple of folks that have dealt with fixing
> breakage in the past.]
>
I’ve submitted a fix for libdnet in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273899 because it blocks 
net/scapy, which we rely on for tests.

I do not plan to fix other ports as well.

Best regards,
Kristof

Fwd: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

[Mark Millard]

[I've cc'd a couple of folks that have dealt with fixing
breakage in the past.]

From: Kristof Provost 
Subject: Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and 
DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged
Date: September 14, 2023 at 02:02:38 PDT
To: Mark Millard 
Cc: Current FreeBSD 
> 
> Hi Mark,
> 
> On 14 Sep 2023, at 7:37, Mark Millard wrote:
>> This change leads the port net/py-libdnet to be broken:
>> 
>> --- fw-pf.lo ---
>> fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
>> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
>> ^
>> fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
>> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
>> ^
>> --- intf.lo ---
>> for (cnt = 0; !matched && cnt < (int) entry->intf_alias_num; cnt++) {
>> ^
>> intf.c:571:2: note: previous statement is here
>> if (entry->intf_addr.addr_type == ADDR_TYPE_IP &&
>> ^
>> --- fw-pf.lo ---
>> fw-pf.c:296:28: error: use of undeclared identifier 'DIOCGETRULE'
>> if ((ret = ioctl(fw->fd, DIOCGETRULE, )) < 0)
>> ^
>> 3 errors generated.
>> 
>> That leads to:
>> 
>> [00:00:41] [29] [00:00:26] Finished net/py-libdnet@py39 | 
>> py39-libdnet-1.13_4: Failed: build
>> [00:00:42] [29] [00:00:27] Skipping net/scapy@py39 | py39-scapy-2.5.0_1: 
>> Dependent port net/py-libdnet@py39 | py39-libdnet-1.13_4 failed
>> 
> 
> The commit removed those ioctls because they’ve been superseded by newer 
> (nvlist-based) versions.
> Ports are strongly advised to use libpfctl rather than trying to deal with 
> nvlists themselves.
> 
> See https://lists.freebsd.org/archives/freebsd-pf/2023-April/000345.html for 
> an example of what the ports will have to do. It’s generally a trivial change.
> 
> Best regards,
> Kristof

===
Mark Millard
marklmi at yahoo.com

Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

[Kristof Provost]

Hi Mark,

On 14 Sep 2023, at 7:37, Mark Millard wrote:
> This change leads the port net/py-libdnet to be broken:
>
> --- fw-pf.lo ---
> fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
> ^
> fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
> ^
> --- intf.lo ---
> for (cnt = 0; !matched && cnt < (int) entry->intf_alias_num; cnt++) {
> ^
> intf.c:571:2: note: previous statement is here
> if (entry->intf_addr.addr_type == ADDR_TYPE_IP &&
> ^
> --- fw-pf.lo ---
> fw-pf.c:296:28: error: use of undeclared identifier 'DIOCGETRULE'
> if ((ret = ioctl(fw->fd, DIOCGETRULE, )) < 0)
> ^
> 3 errors generated.
>
> That leads to:
>
> [00:00:41] [29] [00:00:26] Finished net/py-libdnet@py39 | 
> py39-libdnet-1.13_4: Failed: build
> [00:00:42] [29] [00:00:27] Skipping net/scapy@py39 | py39-scapy-2.5.0_1: 
> Dependent port net/py-libdnet@py39 | py39-libdnet-1.13_4 failed
>

The commit removed those ioctls because they’ve been superseded by newer 
(nvlist-based) versions.
Ports are strongly advised to use libpfctl rather than trying to deal with 
nvlists themselves.

See https://lists.freebsd.org/archives/freebsd-pf/2023-April/000345.html for an 
example of what the ports will have to do. It’s generally a trivial change.

Best regards,
Kristof

Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

[Mark Millard]

This change leads the port net/py-libdnet to be broken:

--- fw-pf.lo ---
fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
^
fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
^
--- intf.lo ---
for (cnt = 0; !matched && cnt < (int) entry->intf_alias_num; cnt++) {
^
intf.c:571:2: note: previous statement is here
if (entry->intf_addr.addr_type == ADDR_TYPE_IP &&
^
--- fw-pf.lo ---
fw-pf.c:296:28: error: use of undeclared identifier 'DIOCGETRULE'
if ((ret = ioctl(fw->fd, DIOCGETRULE, )) < 0)
^
3 errors generated.

That leads to:

[00:00:41] [29] [00:00:26] Finished net/py-libdnet@py39 | py39-libdnet-1.13_4: 
Failed: build
[00:00:42] [29] [00:00:27] Skipping net/scapy@py39 | py39-scapy-2.5.0_1: 
Dependent port net/py-libdnet@py39 | py39-libdnet-1.13_4 failed

net/scapy is used by parts of the kyua testsuite (when installed,
anyway). So the kyua testsuite is now has damaged functionality
on main [so: 15].

===
Mark Millard
marklmi at yahoo.com

See bugzilla's 272965 and 272966 for cortex-A7 armv7 example kyua test case panics for main [so: 14], split by backtrace structure

[Mark Millard]

See:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965
and:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966

All involve 'Alignment Fault' on read at some point
but the 272966 ones first involve: Kernel page fault with
the following non-sleepable locks held during
in6ifa_ifwithaddr.

The 272965 ones involve udp_input getting the alignment
fault.

These reports are based on using the most recent snapshot
of main [so: 14], not based on my own builds. They do
not involve aarch64 at all: no chroot use, no jail use,
no lib32 existing for the already just-armv7 context.

===
Mark Millard
marklmi at yahoo.com

FYI for aarch64/armv7 lib32: armv7 kyua test sys/net/if_bridge_test:gif with preloaded if_bridge.ko still panics in my style of testing

[Mark Millard]

I finally got around to testing lib32 some more, first
trying the panic case that I'd gotten in early testing.
The below is without any special lib32 patching for
testing, just my normal non-debug environment updated
to a lib32-present aarch64 FreeBSD vintage.

Reminder: /usr/obj/DESTDIRs/main-CA7-chroot/ contains an
armv7 installworld distrib-dirs distribution DB_FROM_SRC=1
result. (It also has various ports installed.)

# ~/prekyua-kldloads.sh
. . .
# env \
> LD_32_LIBRARY_PATH=/usr/obj/DESTDIRs/main-CA7-chroot/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/libexec/rtld-elf\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libxo\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/csu/dynamiclib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/tls\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/stdlib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libthr/dlopen\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/lib-dynload\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/CORE\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/auto \
> PATH=/usr/obj/DESTDIRs/main-CA7-chroot/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \
> -k /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/Kyuafile 
> sys/net/if_bridge_test:gif
sys/net/if_bridge_test:gif  ->  Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: 
epair0a: not found
Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: exiting.
Fatal data abort:
  x0: 0xa0275306c560
  x1: 0xa027f9d053d2
  x2: 0x002a
  x3: 0xa0275306c560
  x4: 0xa027f9d053fc
  x5: 0xa0275306c58a
  x6: 0x3ec2
  x7: 0x010006085ba958bc
  x8: 0x002a
  x9: 0x002a
 x10: 0x0008010006085ba9
 x11: 0x58bc3ec201000406
 x12: 0x016433c65ba9
 x13: 0x026433c6
 x14: 0x00ff
 x15: 0x289f
 x16: 0x0002d056b370 (_DYNAMIC + 0x370)
 x17: 0x00598110 (m_dup + 0x0)
 x18: 0x0002801e94a0
 x19: 0x0001
 x20: 0x
 x21: 0x
 x22: 0x00d95000 (vop_spare3_desc + 0x18)
 x23: 0xa0275306c500
 x24: 0xa0275306c500
 x25: 0x00a0
 x26: 0x0002
 x27: 0x
 x28: 0xa0275306c500
 x29: 0x0002801e94c0
  sp: 0x0002801e94a0
  lr: 0x00598308 (m_dup + 0x1f8)
 elr: 0x00598160 (m_dup + 0x50)
spsr: 0x2045
 far: 0x001c
 esr: 0x9604
panic: vm_fault failed: 0x00598160 error 1
cpuid = 14
time = 1690691356
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
data_abort() at data_abort+0x2fc
handle_el1h_sync() at handle_el1h_sync+0x14
--- exception, esr 0x9604
m_dup() at m_dup+0x50
bridge_input() at bridge_input+0x17c
gif_input() at gif_input+0x2dc
in_gif_input() at in_gif_input+0x5c
encap_input() at encap_input+0xfc
encap4_input() at encap4_input+0x30
ip_input() at ip_input+0x5ac
netisr_dispatch_src() at netisr_dispatch_src+0xf8
ether_demux() at ether_demux+0x14c
ether_nh_input() at ether_nh_input+0x39c
netisr_dispatch_src() at netisr_dispatch_src+0xf8
ether_input() at ether_input+0x50
epair_tx_start_deferred() at epair_tx_start_deferred+0x110
taskqueue_run_locked() at taskqueue_run_locked+0x198
taskqueue_thread_loop() at taskqueue_thread_loop+0x130
fork_exit() at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 1028122 ]
Stopped at  kdb_enter+0x44: str xzr, [x19, #3328]

For reference:

# uname -apKU
FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #102 
main-n264334-215bab7924f6-dirty: Wed Jul 26 02:02:48 PDT 2023 
root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
 arm64 aarch64 1400093 1400093



===
Mark Millard
marklmi at yahoo.com

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

On Jul 7, 2023, at 10:13, Mike Karels  wrote:

> On 7 Jul 2023, at 11:38, Mark Millard wrote:
> 
>> On Jul 7, 2023, at 07:36, Mark Millard  wrote:
>> 
>>> On Jul 7, 2023, at 06:50, Mike Karels  wrote:
>>> 
>>>> On 7 Jul 2023, at 6:06, John F Carr wrote:
>>>> 
>>>>> On Jul 6, 2023, at 20:42, Mike Karels  wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks for isolating this.  Let me know when you have the bug number.
>>>>>> I just tested a fix (the compat code drops the reference on the current
>>>>>> address space an extra time, probably freeing it).
>>>>>> 
>>>>>> Mike
>>>> 
>>>> The fix is in 
>>>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
>>>> 
>>>>> The bug was introduced in January, 2022.   It allows 32 bit binaries to 
>>>>> crash a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the 
>>>>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>>>>> 
>>>>> There should be routine runs of 32 bit test suites on 64 bit systems.  
>>>>> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 
>>>>> kernel code needs to be exercised.  This bug was only discovered by 
>>>>> manually running tests in the right environment, 17 months after 
>>>>> automated testing could have discovered it.
>>>> 
>>>> That is not so simple currently, as the shared libraries for the
>>>> test environment are not part of 32-bit compatibility package.
>>>> The required bits could be extracted from the corresponding 32-bit
>>>> build, but that isn't easy to automate.  Fortunately, I think that
>>>> very few of the tests exercise any 32-bit-specific code paths.
>>> 
>>> One way that I demonstrated this problem on an aarch64 system
>>> that supports aarch32/armv7 in user space was via the use of
>>> an official snapshot armv7 image. In my case I:
>>> 
>>> A) dd'd the image to USB3 media (after downloading it)
>>> B) mounted the ufs file system on the media to a mount point
>> 
>> I forgot to mention an important step: before chroot is
>> used, I preload various kernel modules that are used in
>> the Kyuafile tests --because the chroot'd activity will
>> not cause the loads of themsleves but will use the
>> modules if they have already been loaded.
>> 
>>> C) used a chroot into that mount point to run the:
>>>   "kyua test -k /usr/tests/Kyuafile"
>>> 
>>> (I happened to do all that as root.)
>>> 
>>> There may be viable alternatives to dd'ing to allow an analogy to
>>> (B) for (C) to use. I've not experimented with using a jail
>>> instead of a chroot.
>>> 
>>> One can also install an armv7 world into a local directory tree
>>> and then use chroot (or analogous).
>>> 
>>> How far off is an analogous sort of procedure from being reasonable
>>> to automate?
> 
> It would be easier to use the packages rather than the full image
> (base.txz and tests.txz).  But doing this as part of a CI setup would
> mean fetching things from a different source from the install image,
> and then of course doing various configuration.  It's always a Small
> Matter of Programming.  Doing a full chroot gets into some other
> problems, e.g. mdconfig doesn't currently work in compatibility
> mode.  It doesn't seem that automating all this would yield much;
> it's hard enough to do manually.
> 
>>> i386, of course, also has lib32 and independently testing that is
>>> a messier issue, including trying to use /usr/tests/Kyuafile based
>>> testing that avoids use of chroot (or analogous). I'm not claiming
>>> lib32 has as simple of a potential path to automated testing.
> 
> I think the problem is essentially the same.  A chroot could be used
> or a 32-bit library setup (which would test the libraries as well).
> 
>>> I do not know if FreeBSD has powerpc64 hardware able to use a
>>> powerpc world directory tree analogously. Such hardware may be too
>>> old and otherwise problematical, making it not viable to automate
>>> testing.
> 
> Powerpc supports 32-bit libraries, unlike arm (so far).

My understanding is that powerpc64le does not in FreeBSD:
there is no powerpcle in FreeBSD. So, not even chroot style
support for 32-bit little endian use.

If I understand right, no 32 bit little endian ABI is defined,
other than the void linux activity's material, anyway.

It may be that all big endian POWER use has lib32 support, but
I'm not sure if all POWER has big endian FreeBSD support. May
be POWER9 (10?) still has such support in FreeBSD.

===
Mark Millard
marklmi at yahoo.com

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mike Karels]

On 7 Jul 2023, at 11:38, Mark Millard wrote:

> On Jul 7, 2023, at 07:36, Mark Millard  wrote:
>
>> On Jul 7, 2023, at 06:50, Mike Karels  wrote:
>>
>>> On 7 Jul 2023, at 6:06, John F Carr wrote:
>>>
>>>> On Jul 6, 2023, at 20:42, Mike Karels  wrote:
>>>>>
>>>>>
>>>>> Thanks for isolating this.  Let me know when you have the bug number.
>>>>> I just tested a fix (the compat code drops the reference on the current
>>>>> address space an extra time, probably freeing it).
>>>>>
>>>>> Mike
>>>
>>> The fix is in 
>>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
>>>
>>>> The bug was introduced in January, 2022.   It allows 32 bit binaries to 
>>>> crash a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the 
>>>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>>>>
>>>> There should be routine runs of 32 bit test suites on 64 bit systems.  
>>>> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 
>>>> kernel code needs to be exercised.  This bug was only discovered by 
>>>> manually running tests in the right environment, 17 months after automated 
>>>> testing could have discovered it.
>>>
>>> That is not so simple currently, as the shared libraries for the
>>> test environment are not part of 32-bit compatibility package.
>>> The required bits could be extracted from the corresponding 32-bit
>>> build, but that isn't easy to automate.  Fortunately, I think that
>>> very few of the tests exercise any 32-bit-specific code paths.
>>
>> One way that I demonstrated this problem on an aarch64 system
>> that supports aarch32/armv7 in user space was via the use of
>> an official snapshot armv7 image. In my case I:
>>
>> A) dd'd the image to USB3 media (after downloading it)
>> B) mounted the ufs file system on the media to a mount point
>
> I forgot to mention an important step: before chroot is
> used, I preload various kernel modules that are used in
> the Kyuafile tests --because the chroot'd activity will
> not cause the loads of themsleves but will use the
> modules if they have already been loaded.
>
>> C) used a chroot into that mount point to run the:
>>"kyua test -k /usr/tests/Kyuafile"
>>
>> (I happened to do all that as root.)
>>
>> There may be viable alternatives to dd'ing to allow an analogy to
>> (B) for (C) to use. I've not experimented with using a jail
>> instead of a chroot.
>>
>> One can also install an armv7 world into a local directory tree
>> and then use chroot (or analogous).
>>
>> How far off is an analogous sort of procedure from being reasonable
>> to automate?

It would be easier to use the packages rather than the full image
(base.txz and tests.txz).  But doing this as part of a CI setup would
mean fetching things from a different source from the install image,
and then of course doing various configuration.  It's always a Small
Matter of Programming.  Doing a full chroot gets into some other
problems, e.g. mdconfig doesn't currently work in compatibility
mode.  It doesn't seem that automating all this would yield much;
it's hard enough to do manually.

>> i386, of course, also has lib32 and independently testing that is
>> a messier issue, including trying to use /usr/tests/Kyuafile based
>> testing that avoids use of chroot (or analogous). I'm not claiming
>> lib32 has as simple of a potential path to automated testing.

I think the problem is essentially the same.  A chroot could be used
or a 32-bit library setup (which would test the libraries as well).

>> I do not know if FreeBSD has powerpc64 hardware able to use a
>> powerpc world directory tree analogously. Such hardware may be too
>> old and otherwise problematical, making it not viable to automate
>> testing.

Powerpc supports 32-bit libraries, unlike arm (so far).

Mike

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

On Jul 7, 2023, at 07:36, Mark Millard  wrote:

> On Jul 7, 2023, at 06:50, Mike Karels  wrote:
> 
>> On 7 Jul 2023, at 6:06, John F Carr wrote:
>> 
>>> On Jul 6, 2023, at 20:42, Mike Karels  wrote:
>>>> 
>>>> 
>>>> Thanks for isolating this.  Let me know when you have the bug number.
>>>> I just tested a fix (the compat code drops the reference on the current
>>>> address space an extra time, probably freeing it).
>>>> 
>>>> Mike
>> 
>> The fix is in 
>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
>> 
>>> The bug was introduced in January, 2022.   It allows 32 bit binaries to 
>>> crash a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the 
>>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>>> 
>>> There should be routine runs of 32 bit test suites on 64 bit systems.  
>>> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 
>>> kernel code needs to be exercised.  This bug was only discovered by 
>>> manually running tests in the right environment, 17 months after automated 
>>> testing could have discovered it.
>> 
>> That is not so simple currently, as the shared libraries for the
>> test environment are not part of 32-bit compatibility package.
>> The required bits could be extracted from the corresponding 32-bit
>> build, but that isn't easy to automate.  Fortunately, I think that
>> very few of the tests exercise any 32-bit-specific code paths.
> 
> One way that I demonstrated this problem on an aarch64 system
> that supports aarch32/armv7 in user space was via the use of
> an official snapshot armv7 image. In my case I:
> 
> A) dd'd the image to USB3 media (after downloading it)
> B) mounted the ufs file system on the media to a mount point

I forgot to mention an important step: before chroot is
used, I preload various kernel modules that are used in
the Kyuafile tests --because the chroot'd activity will
not cause the loads of themsleves but will use the
modules if they have already been loaded.

> C) used a chroot into that mount point to run the:
>"kyua test -k /usr/tests/Kyuafile"
> 
> (I happened to do all that as root.)
> 
> There may be viable alternatives to dd'ing to allow an analogy to
> (B) for (C) to use. I've not experimented with using a jail
> instead of a chroot.
> 
> One can also install an armv7 world into a local directory tree
> and then use chroot (or analogous).
> 
> How far off is an analogous sort of procedure from being reasonable
> to automate?
> 
> i386, of course, also has lib32 and independently testing that is
> a messier issue, including trying to use /usr/tests/Kyuafile based
> testing that avoids use of chroot (or analogous). I'm not claiming
> lib32 has as simple of a potential path to automated testing.
> 
> I do not know if FreeBSD has powerpc64 hardware able to use a
> powerpc world directory tree analogously. Such hardware may be too
> old and otherwise problematical, making it not viable to automate
> testing.
> 



===
Mark Millard
marklmi at yahoo.com

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

On Jul 7, 2023, at 06:50, Mike Karels  wrote:

> On 7 Jul 2023, at 6:06, John F Carr wrote:
> 
>> On Jul 6, 2023, at 20:42, Mike Karels  wrote:
>>> 
>>> 
>>> Thanks for isolating this.  Let me know when you have the bug number.
>>> I just tested a fix (the compat code drops the reference on the current
>>> address space an extra time, probably freeing it).
>>> 
>>> Mike
> 
> The fix is in 
> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
> 
>> The bug was introduced in January, 2022.   It allows 32 bit binaries to 
>> crash a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the 
>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>> 
>> There should be routine runs of 32 bit test suites on 64 bit systems.  
>> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 
>> kernel code needs to be exercised.  This bug was only discovered by manually 
>> running tests in the right environment, 17 months after automated testing 
>> could have discovered it.
> 
> That is not so simple currently, as the shared libraries for the
> test environment are not part of 32-bit compatibility package.
> The required bits could be extracted from the corresponding 32-bit
> build, but that isn't easy to automate.  Fortunately, I think that
> very few of the tests exercise any 32-bit-specific code paths.

One way that I demonstrated this problem on an aarch64 system
that supports aarch32/armv7 in user space was via the use of
an official snapshot armv7 image. In my case I:

A) dd'd the image to USB3 media (after downloading it)
B) mounted the ufs file system on the media to a mount point
C) used a chroot into that mount point to run the:
"kyua test -k /usr/tests/Kyuafile"

(I happened to do all that as root.)

There may be viable alternatives to dd'ing to allow an analogy to
(B) for (C) to use. I've not experimented with using a jail
instead of a chroot.

One can also install an armv7 world into a local directory tree
and then use chroot (or analogous).

How far off is an analogous sort of procedure from being reasonable
to automate?

i386, of course, also has lib32 and independently testing that is
a messier issue, including trying to use /usr/tests/Kyuafile based
testing that avoids use of chroot (or analogous). I'm not claiming
lib32 has as simple of a potential path to automated testing.

I do not know if FreeBSD has powerpc64 hardware able to use a
powerpc world directory tree analogously. Such hardware may be too
old and otherwise problematical, making it not viable to automate
testing.

===
Mark Millard
marklmi at yahoo.com

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mike Karels]

On 7 Jul 2023, at 6:06, John F Carr wrote:

> On Jul 6, 2023, at 20:42, Mike Karels  wrote:
>>
>>
>> Thanks for isolating this.  Let me know when you have the bug number.
>> I just tested a fix (the compat code drops the reference on the current
>> address space an extra time, probably freeing it).
>>
>> Mike

The fix is in 
https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.

> The bug was introduced in January, 2022.   It allows 32 bit binaries to crash 
> a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the buggy 
> function (sysctl_kern_proc_vm_layout) was added at the same time.
>
> There should be routine runs of 32 bit test suites on 64 bit systems.  
> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 
> kernel code needs to be exercised.  This bug was only discovered by manually 
> running tests in the right environment, 17 months after automated testing 
> could have discovered it.

That is not so simple currently, as the shared libraries for the
test environment are not part of 32-bit compatibility package.
The required bits could be extracted from the corresponding 32-bit
build, but that isn't easy to automate.  Fortunately, I think that
very few of the tests exercise any 32-bit-specific code paths.

Mike

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[John F Carr]

On Jul 6, 2023, at 20:42, Mike Karels  wrote:
> 
> 
> Thanks for isolating this.  Let me know when you have the bug number.
> I just tested a fix (the compat code drops the reference on the current
> address space an extra time, probably freeing it).
> 
> Mike

The bug was introduced in January, 2022.   It allows 32 bit binaries to crash a 
64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the buggy function 
(sysctl_kern_proc_vm_layout) was added at the same time.

There should be routine runs of 32 bit test suites on 64 bit systems.  Although 
i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 kernel code 
needs to be exercised.  This bug was only discovered by manually running tests 
in the right environment, 17 months after automated testing could have 
discovered it.

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mike Karels]

On 6 Jul 2023, at 18:53, John F Carr wrote:

> The hang is caused by the sysctl call in tests/sys/kern/kern_copyin.c.  The 
> function below hangs when called in a 32 bit ARM process running in a chroot 
> environment on a 64 bit ARM system.  I will write up a bug report.
>
> static int
> get_vm_layout(struct kinfo_vm_layout *kvm)
> {
>   size_t len;
>   int mib[4];
>
>   mib[0] = CTL_KERN;
>   mib[1] = KERN_PROC;
>   mib[2] = KERN_PROC_VM_LAYOUT;
>   mib[3] = getpid();
>   len = sizeof(*kvm);
>
>   return (sysctl(mib, nitems(mib), kvm, , NULL, 0));
> }

Thanks for isolating this.  Let me know when you have the bug number.
I just tested a fix (the compat code drops the reference on the current
address space an extra time, probably freeing it).

Mike

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

On Jul 6, 2023, at 16:53, John F Carr  wrote:

> On Jun 25, 2023, at 20:16, Mark Millard  wrote:
>> 
>> . . .
>> 
> 
> The hang is caused by the sysctl call in tests/sys/kern/kern_copyin.c.  The 
> function below hangs when called in a 32 bit ARM process running in a chroot 
> environment on a 64 bit ARM system.  I will write up a bug report.
> 
> static int
> get_vm_layout(struct kinfo_vm_layout *kvm)
> {
> size_t len;
> int mib[4];
> 
> mib[0] = CTL_KERN;
> mib[1] = KERN_PROC;
> mib[2] = KERN_PROC_VM_LAYOUT;
> mib[3] = getpid();
> len = sizeof(*kvm);
> 
> return (sysctl(mib, nitems(mib), kvm, , NULL, 0));
> }
> 

Thanks for the tiny-reproducer analysis! That should help
make getting to a fix more actionable.

===
Mark Millard
marklmi at yahoo.com

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[John F Carr]

> On Jun 25, 2023, at 20:16, Mark Millard  wrote:
> 
> Using the likes of:
> 
> FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230622-b95d2237af40-263748.img
> and:
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230622-b95d2237af40-263748.img
> 
> I have shown the following behavior after setting up storage
> media based on them. (This was a test that my builds were not
> odd for the issue.)
> 
> Boot the aarch64 media and log in. (Note: I logged in
> as root.)
> 
> mount the armv7 media (-noatime is just my habit)
> and then put it to use:
> 
> # mount -onoatime /dev/da1s2a /mnt
> 
> # chroot /mnt/
> 
> # kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin
> sys/kern/kern_copyin:kern_copyin  ->  
> 
> On the serial console:
> 
> # ps -xu
> USER  PID   %CPU %MEM   VSZ  RSS TT  STAT STARTED  TIME COMMAND
> root   11 1498.4  0.0 0  256  -  RNL  23:24   542:52.92 [idle]
> root 1174  100.0  0.0 0   16  -  Rs   23:37 0:00.00 
> /usr/tests/sys/kern/kern_copyin -vunprivileged-user=tests 
> -r/tmp/kyua.9YUttj/2/result.atf kern_copyin
> root00.0  0.0 0 1616  -  DLs  23:24 0:00.50 [kernel]
> root10.0  0.0 11704 1288  -  ILs  23:24 0:00.02 /sbin/init
> root20.0  0.0 0  256  -  WL   23:24 0:00.26 [clock]
> root30.0  0.0 0  272  -  DL   23:24 0:00.00 [crypto]
> root40.0  0.0 0   80  -  DL   23:24 0:00.95 [cam]
> root50.0  0.0 0   16  -  DL   23:24 0:00.00 [busdma]
> root60.0  0.0 0   16  -  DL   23:24 0:00.03 [rand_harvestq]
> root70.0  0.0 0   48  -  DL   23:24 0:00.06 [pagedaemon]
> root80.0  0.0 0   16  -  DL   23:24 0:00.00 [vmdaemon]
> root90.0  0.0 0  160  -  DL   23:24 0:00.38 [bufdaemon]
> root   100.0  0.0 0   16  -  DL   23:24 0:00.00 [audit]
> root   120.0  0.0 0  880  -  WL   23:24 0:11.81 [intr]
> root   130.0  0.0 0   48  -  DL   23:24 0:00.04 [geom]
> root   140.0  0.0 0   16  -  DL   23:24 0:00.00 [sequencer 00]
> root   150.0  0.0 0  160  -  DL   23:24 0:06.42 [usb]
> root   160.0  0.0 0   16  -  DL   23:24 0:00.10 [acpi_thermal]
> root   170.0  0.0 0   16  -  DL   23:24 0:00.00 [acpi_cooling0]
> root   180.0  0.0 0   16  -  DL   23:24 0:00.04 [syncer]
> root   190.0  0.0 0   16  -  DL   23:24 0:00.00 [vnlru]
> root  6710.0  0.0 13260 2600  -  Is   23:25 0:00.00 dhclient: 
> system.syslog (dhclient)
> root  6740.0  0.0 13260 2752  -  Is   23:25 0:00.00 dhclient: dpni0 
> [priv] (dhclient)
> root  7610.0  0.0 14572 3972  -  Ss   23:25 0:00.02 /sbin/devd
> root  9640.0  0.0 12832 2764  -  Is   23:25 0:00.02 /usr/sbin/syslogd 
> -s
> root 10330.0  0.0 13012 2604  -  Ss   23:25 0:00.01 /usr/sbin/cron -s
> root 10580.0  0.0 21052 8308  -  Is   23:25 0:00.01 sshd: 
> /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
> root 10780.0  0.0 21288 9304  -  Is   23:26 0:00.09 sshd: root@pts/0 
> (sshd)
> root 11750.0  0.0 21288 9496  -  Is   23:37 0:00.04 sshd: root@pts/1 
> (sshd)
> root 10740.0  0.0 13380 3008 u0  Is   23:25 0:00.01 login [pam] 
> (login)
> root 10750.0  0.0 13460 3292 u0  S23:25 0:00.02 -sh (sh)
> root 12330.0  0.0 13588 3016 u0  R+   00:00 0:00.00 ps -xu
> root 10810.0  0.0 13460 3328  0  Is   23:26 0:00.02 -sh (sh)
> root 11700.0  0.0  5788 2884  0  I23:36 0:00.02 /bin/sh -i
> root 11720.0  0.0 10408 7192  0  I+   23:37 0:00.30 kyua test -k 
> /usr/tests/Kyuafile sys/kern/kern_copyin
> root 11780.0  0.0 13460 3320  1  Is+  23:38 0:00.01 -sh (sh)
> 
> 1174 is stuck, even if one waits for 30min+.
> kill and kill -9 will not kill 1174.
> 
> "shutdown -r now" hangs before the reboot happens
> and reports: "some processes would not die".
> 
> An interesting property is that ps and top disagree
> about 1174 CPU usage: ps 100%, top 0%. But top also
> indicates 1174 always has CPU0 "STATE". (Across
> tests CPUn varies but within a test it has
> a fixed n.)
> 
> I have also seen ps "STAT" being RXs.
> 
> The following is from my earlier activity with my own
> builds involved, here 1119, not the 1174 from above.
> truss reports as the last thing for the stuck process
> as "getpid()".
> 
> . . .
> 1119: 0.588983953 fstatat(AT_FDCWD,"/usr/tests/sys/kern/kern_copyin",{ 
> mode=-r-xr-xr-x ,inode=111756,size=9776,blksize=10240 },AT_SYMLINK_NOFOLLOW) 
> = 0 (0x0)
> 1119: 0.589065030 
> mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANO

Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

On Jun 25, 2023, at 17:16, Mark Millard  wrote:

> Using the likes of:
> 
> FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230622-b95d2237af40-263748.img
> and:
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230622-b95d2237af40-263748.img
> 
> I have shown the following behavior after setting up storage
> media based on them. (This was a test that my builds were not
> odd for the issue.)
> 
> Boot the aarch64 media and log in. (Note: I logged in
> as root.)
> 
> mount the armv7 media (-noatime is just my habit)
> and then put it to use:
> 
> # mount -onoatime /dev/da1s2a /mnt
> 
> # chroot /mnt/
> 
> # kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin
> sys/kern/kern_copyin:kern_copyin  ->  
> 
> On the serial console:
> 
> # ps -xu
> USER  PID   %CPU %MEM   VSZ  RSS TT  STAT STARTED  TIME COMMAND
> root   11 1498.4  0.0 0  256  -  RNL  23:24   542:52.92 [idle]
> root 1174  100.0  0.0 0   16  -  Rs   23:37 0:00.00 
> /usr/tests/sys/kern/kern_copyin -vunprivileged-user=tests 
> -r/tmp/kyua.9YUttj/2/result.atf kern_copyin
> root00.0  0.0 0 1616  -  DLs  23:24 0:00.50 [kernel]
> root10.0  0.0 11704 1288  -  ILs  23:24 0:00.02 /sbin/init
> root20.0  0.0 0  256  -  WL   23:24 0:00.26 [clock]
> root30.0  0.0 0  272  -  DL   23:24 0:00.00 [crypto]
> root40.0  0.0 0   80  -  DL   23:24 0:00.95 [cam]
> root50.0  0.0 0   16  -  DL   23:24 0:00.00 [busdma]
> root60.0  0.0 0   16  -  DL   23:24 0:00.03 [rand_harvestq]
> root70.0  0.0 0   48  -  DL   23:24 0:00.06 [pagedaemon]
> root80.0  0.0 0   16  -  DL   23:24 0:00.00 [vmdaemon]
> root90.0  0.0 0  160  -  DL   23:24 0:00.38 [bufdaemon]
> root   100.0  0.0 0   16  -  DL   23:24 0:00.00 [audit]
> root   120.0  0.0 0  880  -  WL   23:24 0:11.81 [intr]
> root   130.0  0.0 0   48  -  DL   23:24 0:00.04 [geom]
> root   140.0  0.0 0   16  -  DL   23:24 0:00.00 [sequencer 00]
> root   150.0  0.0 0  160  -  DL   23:24 0:06.42 [usb]
> root   160.0  0.0 0   16  -  DL   23:24 0:00.10 [acpi_thermal]
> root   170.0  0.0 0   16  -  DL   23:24 0:00.00 [acpi_cooling0]
> root   180.0  0.0 0   16  -  DL   23:24 0:00.04 [syncer]
> root   190.0  0.0 0   16  -  DL   23:24 0:00.00 [vnlru]
> root  6710.0  0.0 13260 2600  -  Is   23:25 0:00.00 dhclient: 
> system.syslog (dhclient)
> root  6740.0  0.0 13260 2752  -  Is   23:25 0:00.00 dhclient: dpni0 
> [priv] (dhclient)
> root  7610.0  0.0 14572 3972  -  Ss   23:25 0:00.02 /sbin/devd
> root  9640.0  0.0 12832 2764  -  Is   23:25 0:00.02 /usr/sbin/syslogd 
> -s
> root 10330.0  0.0 13012 2604  -  Ss   23:25 0:00.01 /usr/sbin/cron -s
> root 10580.0  0.0 21052 8308  -  Is   23:25 0:00.01 sshd: 
> /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
> root 10780.0  0.0 21288 9304  -  Is   23:26 0:00.09 sshd: root@pts/0 
> (sshd)
> root 11750.0  0.0 21288 9496  -  Is   23:37 0:00.04 sshd: root@pts/1 
> (sshd)
> root 10740.0  0.0 13380 3008 u0  Is   23:25 0:00.01 login [pam] 
> (login)
> root 10750.0  0.0 13460 3292 u0  S23:25 0:00.02 -sh (sh)
> root 12330.0  0.0 13588 3016 u0  R+   00:00 0:00.00 ps -xu
> root 10810.0  0.0 13460 3328  0  Is   23:26 0:00.02 -sh (sh)
> root 11700.0  0.0  5788 2884  0  I23:36 0:00.02 /bin/sh -i
> root 11720.0  0.0 10408 7192  0  I+   23:37 0:00.30 kyua test -k 
> /usr/tests/Kyuafile sys/kern/kern_copyin
> root 11780.0  0.0 13460 3320  1  Is+  23:38 0:00.01 -sh (sh)
> 
> 1174 is stuck, even if one waits for 30min+.
> kill and kill -9 will not kill 1174.
> 
> "shutdown -r now" hangs before the reboot happens
> and reports: "some processes would not die".
> 
> An interesting property is that ps and top disagree
> about 1174 CPU usage: ps 100%, top 0%. But top also
> indicates 1174 always has CPU0 "STATE". (Across
> tests CPUn varies but within a test it has
> a fixed n.)
> 
> I have also seen ps "STAT" being RXs.
> 
> The following is from my earlier activity with my own
> builds involved, here 1119, not the 1174 from above.
> truss reports as the last thing for the stuck process
> as "getpid()".
> 
> . . .
> 1119: 0.588983953 fstatat(AT_FDCWD,"/usr/tests/sys/kern/kern_copyin",{ 
> mode=-r-xr-xr-x ,inode=111756,size=9776,blksize=10240 },AT_SYMLINK_NOFOLLOW) 
> = 0 (0x0)
> 1119: 0.589065030 
> mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(

For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

[Mark Millard]

Using the likes of:

FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230622-b95d2237af40-263748.img
and:
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230622-b95d2237af40-263748.img

I have shown the following behavior after setting up storage
media based on them. (This was a test that my builds were not
odd for the issue.)

Boot the aarch64 media and log in. (Note: I logged in
as root.)

mount the armv7 media (-noatime is just my habit)
and then put it to use:

# mount -onoatime /dev/da1s2a /mnt

# chroot /mnt/

# kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin
sys/kern/kern_copyin:kern_copyin  ->  

On the serial console:

# ps -xu
USER  PID   %CPU %MEM   VSZ  RSS TT  STAT STARTED  TIME COMMAND
root   11 1498.4  0.0 0  256  -  RNL  23:24   542:52.92 [idle]
root 1174  100.0  0.0 0   16  -  Rs   23:37 0:00.00 
/usr/tests/sys/kern/kern_copyin -vunprivileged-user=tests 
-r/tmp/kyua.9YUttj/2/result.atf kern_copyin
root00.0  0.0 0 1616  -  DLs  23:24 0:00.50 [kernel]
root10.0  0.0 11704 1288  -  ILs  23:24 0:00.02 /sbin/init
root20.0  0.0 0  256  -  WL   23:24 0:00.26 [clock]
root30.0  0.0 0  272  -  DL   23:24 0:00.00 [crypto]
root40.0  0.0 0   80  -  DL   23:24 0:00.95 [cam]
root50.0  0.0 0   16  -  DL   23:24 0:00.00 [busdma]
root60.0  0.0 0   16  -  DL   23:24 0:00.03 [rand_harvestq]
root70.0  0.0 0   48  -  DL   23:24 0:00.06 [pagedaemon]
root80.0  0.0 0   16  -  DL   23:24 0:00.00 [vmdaemon]
root90.0  0.0 0  160  -  DL   23:24 0:00.38 [bufdaemon]
root   100.0  0.0 0   16  -  DL   23:24 0:00.00 [audit]
root   120.0  0.0 0  880  -  WL   23:24 0:11.81 [intr]
root   130.0  0.0 0   48  -  DL   23:24 0:00.04 [geom]
root   140.0  0.0 0   16  -  DL   23:24 0:00.00 [sequencer 00]
root   150.0  0.0 0  160  -  DL   23:24 0:06.42 [usb]
root   160.0  0.0 0   16  -  DL   23:24 0:00.10 [acpi_thermal]
root   170.0  0.0 0   16  -  DL   23:24 0:00.00 [acpi_cooling0]
root   180.0  0.0 0   16  -  DL   23:24 0:00.04 [syncer]
root   190.0  0.0 0   16  -  DL   23:24 0:00.00 [vnlru]
root  6710.0  0.0 13260 2600  -  Is   23:25 0:00.00 dhclient: 
system.syslog (dhclient)
root  6740.0  0.0 13260 2752  -  Is   23:25 0:00.00 dhclient: dpni0 
[priv] (dhclient)
root  7610.0  0.0 14572 3972  -  Ss   23:25 0:00.02 /sbin/devd
root  9640.0  0.0 12832 2764  -  Is   23:25 0:00.02 /usr/sbin/syslogd -s
root 10330.0  0.0 13012 2604  -  Ss   23:25 0:00.01 /usr/sbin/cron -s
root 10580.0  0.0 21052 8308  -  Is   23:25 0:00.01 sshd: 
/usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
root 10780.0  0.0 21288 9304  -  Is   23:26 0:00.09 sshd: root@pts/0 
(sshd)
root 11750.0  0.0 21288 9496  -  Is   23:37 0:00.04 sshd: root@pts/1 
(sshd)
root 10740.0  0.0 13380 3008 u0  Is   23:25 0:00.01 login [pam] (login)
root 10750.0  0.0 13460 3292 u0  S23:25 0:00.02 -sh (sh)
root 12330.0  0.0 13588 3016 u0  R+   00:00 0:00.00 ps -xu
root 10810.0  0.0 13460 3328  0  Is   23:26 0:00.02 -sh (sh)
root 11700.0  0.0  5788 2884  0  I23:36 0:00.02 /bin/sh -i
root 11720.0  0.0 10408 7192  0  I+   23:37 0:00.30 kyua test -k 
/usr/tests/Kyuafile sys/kern/kern_copyin
root 11780.0  0.0 13460 3320  1  Is+  23:38 0:00.01 -sh (sh)

1174 is stuck, even if one waits for 30min+.
kill and kill -9 will not kill 1174.

"shutdown -r now" hangs before the reboot happens
and reports: "some processes would not die".

An interesting property is that ps and top disagree
about 1174 CPU usage: ps 100%, top 0%. But top also
indicates 1174 always has CPU0 "STATE". (Across
tests CPUn varies but within a test it has
a fixed n.)

I have also seen ps "STAT" being RXs.

The following is from my earlier activity with my own
builds involved, here 1119, not the 1174 from above.
truss reports as the last thing for the stuck process
as "getpid()".

. . .
1119: 0.588983953 fstatat(AT_FDCWD,"/usr/tests/sys/kern/kern_copyin",{ 
mode=-r-xr-xr-x ,inode=111756,size=9776,blksize=10240 },AT_SYMLINK_NOFOLLOW) = 
0 (0x0)
1119: 0.589065030 
mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
 = 1074188288 (0x4006d000)
1119: 0.589227544 
openat(AT_FDCWD,"/tmp/kyua.aBQv6E/2/result.atf",O_WRONLY|O_CREAT|O_TRUNC,0644) 
= 3 (0x3)
1119: 0.589276503 getpid()  = 1119 (0x45f)



For reference, from inside an armv7 chroot session
before doing such a test:

# uname -apKU
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263748-b95d2237af40: 
Thu Jun 22 11:10:50 UTC 2023 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm 
armv7 1400090 1400090

===
Mark Millard
marklmi at yahoo.com

Re: FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile (info for some more examples)

[Mark Millard]

On 2022-Jan-9, at 13:47, Mark Millard  wrote:

> On 2022-Jan-7, at 03:39, Mark Millard  wrote:
> 
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use and have
>> "kyua test -k /usr/tests/Kyuafile" running.
>> 
>> I see evidence of one AddressSanitizer report. (kyua is still
>> running.) The context is:
>> 
>> # more 
>> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt 
>> Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ]
>> mount -t tmpfs -o size=10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt
>> Executing command [ touch a ]
>> Executing command [ rm a ]
>> Executing command [ dd if=/dev/zero of=a bs=1m count=15 ]
>> Executing command [ rm a ]
>> 
>> # more 
>> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt 
>> =
>> ==14384==ERROR: AddressSanitizer: stack-buffer-overflow on address 
>> 0x7fffa948 at pc 0x000801f38f5a bp 0x7fffa830 sp 0x7fffa828
>> WRITE of size 8 at 0x7fffa948 thread T0
>>   #0 0x801f38f59 in strtoimax_l 
>> /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11
>>   #1 0x10de6c8 in strtoimax 
>> /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:3441:18
>>   #2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6
>>   #3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7
>>   #4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10
>>   #5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10
>>   #6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9
>>   #7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8
>>   #8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10
>>   #9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8
>>   #10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10
>>   #11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16
>>   #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>>   #13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4
>>   #14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4
>>   #15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>>   #16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>>   #17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4
>>   #18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>>   #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>>   #20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>>   #21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>>   #22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c
>>   #23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3
>> 
>> Address 0x7fffa948 is located in stack of thread T0 at offset 264 in 
>> frame
>>   #0 0x801f387ff in strtoimax_l /usr/main-src/lib/libc/stdlib/strtoimax.c:58
>> 
>> This frame has 1 object(s):
>>   [32, 36) '__limit.i.i.i' <== Memory access at offset 264 overflows this 
>> variable
>> HINT: this may be a false positive if your program uses some custom stack 
>> unwind mechanism, swapcontext or vfork
>> (longjmp and C++ exceptions *are* supported)
>> SUMMARY: AddressSanitizer: stack-buffer-overflow 
>> /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l
>> Shadow bytes around the buggy address:
>> 0x44d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 0x44e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 0x44f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 0x4500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3
>> 0x4510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> =>0x4520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00
>> 0x4530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00
>> 0x4540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00
>> 0x4550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> 0x4560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> 0x4570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8
>> Shadow byte legend (one shadow byte represents 8 application bytes):
>> Addressable:   00
>> Partially addressable: 01 02 03 04 05 06 07 
>> Heap left redzone:   fa
>> Freed heap region:   fd
>> Stack left redzone:  f1
>> Stack mid redzone:   f2
>> Stack right redzone: 

Re: FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile (info for some more examples)

[Mark Millard]

On 2022-Jan-7, at 03:39, Mark Millard  wrote:

> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
> 
> I see evidence of one AddressSanitizer report. (kyua is still
> running.) The context is:
> 
> # more 
> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt 
> Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ]
> mount -t tmpfs -o size=10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt
> Executing command [ touch a ]
> Executing command [ rm a ]
> Executing command [ dd if=/dev/zero of=a bs=1m count=15 ]
> Executing command [ rm a ]
> 
> # more 
> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt 
> =
> ==14384==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x7fffa948 at pc 0x000801f38f5a bp 0x7fffa830 sp 0x7fffa828
> WRITE of size 8 at 0x7fffa948 thread T0
>#0 0x801f38f59 in strtoimax_l 
> /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11
>#1 0x10de6c8 in strtoimax 
> /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:3441:18
>#2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6
>#3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7
>#4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10
>#5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10
>#6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9
>#7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8
>#8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10
>#9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8
>#10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10
>#11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16
>#12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>#13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4
>#14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4
>#15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>#16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>#17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4
>#18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>#19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>#20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
>#21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
>#22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c
>#23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3
> 
> Address 0x7fffa948 is located in stack of thread T0 at offset 264 in frame
>#0 0x801f387ff in strtoimax_l /usr/main-src/lib/libc/stdlib/strtoimax.c:58
> 
>  This frame has 1 object(s):
>[32, 36) '__limit.i.i.i' <== Memory access at offset 264 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism, swapcontext or vfork
>  (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: stack-buffer-overflow 
> /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l
> Shadow bytes around the buggy address:
>  0x44d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  0x44e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  0x44f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  0x4500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3
>  0x4510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x4520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00
>  0x4530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00
>  0x4540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00
>  0x4550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  0x4560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  0x4570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8
> Shadow byte legend (one shadow byte represents 8 application bytes):
>  Addressable:   00
>  Partially addressable: 01 02 03 04 05 06 07 
>  Heap left redzone:   fa
>  Freed heap region:   fd
>  Stack left redzone:  f1
>  Stack mid redzone:   f2
>  Stack right redzone: f3
>  Stack after return:  f5
>  Stack use after scope:   f8
>  Global redzone:  f9
>  Global init order:   f6
>  Poisoned by user:f7
>  Container overflow:  fc
>  Array cookie:ac
>  Intra object redzone:bb
>  ASan internal:   fe
>  Left alloca redzone:

Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile

[Mark Millard]

On 2022-Jan-7, at 04:31, Stefan Esser  wrote:

> Am 07.01.22 um 12:49 schrieb Mark Millard:
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use and have
>> "kyua test -k /usr/tests/Kyuafile" running.
>> 
>> I see evidence of various examples of one type of undefined
>> behavior: "applying zero offset to null pointer"
>> 
>> # more 
>> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/usr.bin/sed/process.c:715:18 in 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> Fail: stderr not empty
>> --- /dev/null   2022-01-07 10:29:57.182903000 +
>> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr   2022-01-07 
>> 10:29:57.17310 +
>> @@ -0,0 +1,2 @@
>> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> Files left in work directory after failure: mntpt, mounterr
>> 
>> 
>> In general the lib/libc/stdio/fread.c:133:10 example seems to
>> be in a place that would make it fairly common.
> 
> Interesting find:
> 
>while (resid > (r = fp->_r)) {
>(void)memcpy((void *)p, (void *)fp->_p, (size_t)r);
>fp->_p += r; /* line 133 */
>/* fp->_r = 0 ... done in __srefill */
>p += r;
>resid -= r;
> 
> If fp->_p == NULL in line 133, then NULL has been passed as source address
> in memcpy() in the line above, and I'd think that is undefined behavior,
> even if a length of 0 is passed at the same time.

My copy of ISO/IEC 9899:2011 (E) only explicitly mentions such a
limitation for the memcpy_s variant.  It does say "[t]he memcpy
function returns the value of s1". The only mentioned "behavior
is undefined" is for copying between objects that overlap.

But there is more general wording in 7.24.1 (of 7.24 String
handling ):

QUOTE
Where an argument declared as size_t n specifies the length
of the array for a function, n can have the value zero on a
call to that function. Unless explicitly stated otherwise in
the description of a particular function in this subclause,
pointer arguments on such a call still shall have valid values,
as described in 7.1.4. On such a call, . . . a function that
copies characters copies zero characters.
END QUOTE

But I've not noticed anything in 7.1.4 is that explicit about
NULL arguments with zero sizes or that bans NULL arguments
in any generality.

In other words, I believe that the lack of a report for memcpy's
argument values is consistent with what ISO/IEC 9899:2011
is explicit about for such things.

I've not tried going through POSIX material or any other
potential standards.

> Maybe the code block quoted above (line 132 to 136) should be made wrapped
> into "if (r > 0) {}"?
> 


===
Mark Millard
marklmi at yahoo.com

Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile

[Mark Millard]

On 2022-Jan-7, at 05:08, Mark Millard  wrote:

> On 2022-Jan-7, at 03:49, Mark Millard  wrote:
> 
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use and have
>> "kyua test -k /usr/tests/Kyuafile" running.
>> 
>> I see evidence of various examples of one type of undefined
>> behavior: "applying zero offset to null pointer"
>> 
>> # more 
>> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/usr.bin/sed/process.c:715:18 in 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> Fail: stderr not empty
>> --- /dev/null   2022-01-07 10:29:57.182903000 +
>> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr   2022-01-07 
>> 10:29:57.17310 +
>> @@ -0,0 +1,2 @@
>> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
>> offset to null pointer
>> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
>> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
>> Files left in work directory after failure: mntpt, mounterr
>> 
>> 
>> In general the lib/libc/stdio/fread.c:133:10 example seems to
>> be in a place that would make it fairly common.
>> 
>> usr.bin/sed/process.c:715:18 is more limited: just sed use.
>> 
> 
> kyua ran to completion. This note is focused on UBSAN reports.
> 
> By far the most common UBSAN report is for the
> lib/libc/stdio/fread.c:133:10 code.
> 
> Another somewhat common UBSAN report is:
> 
> Standard error:
> /usr/main-src/usr.bin/cut/cut.c:458:7: runtime error: addition of unsigned 
> offset to 0x6210010d overflowed to 0x6210010c
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/usr.bin/cut/cut.c:458:7 in 
> Fail: incorrect exit status: 1, expected: 0
> 
> 
> There is at least one example of:
> 
> Standard error:
> ld-elf.so.1: /lib/libthr.so.3: Undefined symbol 
> "__asan_option_detect_stack_use_after_return"
> 
> 
> Some more zero offsets to null are:
> 
> +/usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero offset to 
> null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/bin/sh/jobs.c:590:35 in 
> +/usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset to 
> null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/bin/sh/jobs.c:601:22 in 
> +/usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16: runtime error: 
> applying zero offset to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16 in 
> 
> +/usr/main-src/usr.sbin/makefs/ffs.c:1053:35: runtime error: applying zero 
> offset to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/usr.sbin/makefs/ffs.c:1053:35 in 
> Files left in work directory after failure: dir, ufs.img
> 
> 
> contrib/libxo/libxo/xo_buf.h has examples of non-zero offsets:
> 
> +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22: runtime error: applying 
> non-zero offset 4 to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22 in 
> +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44: runtime error: applying 
> zero offset to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44 in 
> +/usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29: runtime error: applying 
> non-zero offset 4 to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29 in 
> 
> As does contrib/openzfs/module/nvpair/nvpair.c :
> 

Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile

[Mark Millard]

On 2022-Jan-7, at 03:49, Mark Millard  wrote:

> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
> 
> I see evidence of various examples of one type of undefined
> behavior: "applying zero offset to null pointer"
> 
> # more 
> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/usr.bin/sed/process.c:715:18 in 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> Fail: stderr not empty
> --- /dev/null   2022-01-07 10:29:57.182903000 +
> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr   2022-01-07 
> 10:29:57.17310 +
> @@ -0,0 +1,2 @@
> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> Files left in work directory after failure: mntpt, mounterr
> 
> 
> In general the lib/libc/stdio/fread.c:133:10 example seems to
> be in a place that would make it fairly common.
> 
> usr.bin/sed/process.c:715:18 is more limited: just sed use.
> 

kyua ran to completion. This note is focused on UBSAN reports.

By far the most common UBSAN report is for the
lib/libc/stdio/fread.c:133:10 code.

Another somewhat common UBSAN report is:

Standard error:
/usr/main-src/usr.bin/cut/cut.c:458:7: runtime error: addition of unsigned 
offset to 0x6210010d overflowed to 0x6210010c
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/usr.bin/cut/cut.c:458:7 in 
Fail: incorrect exit status: 1, expected: 0


There is at least one example of:

Standard error:
ld-elf.so.1: /lib/libthr.so.3: Undefined symbol 
"__asan_option_detect_stack_use_after_return"


Some more zero offsets to null are:

+/usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero offset to 
null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/bin/sh/jobs.c:590:35 in 
+/usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset to 
null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/bin/sh/jobs.c:601:22 in 
+/usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16: runtime error: 
applying zero offset to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16 in 

+/usr/main-src/usr.sbin/makefs/ffs.c:1053:35: runtime error: applying zero 
offset to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/usr.sbin/makefs/ffs.c:1053:35 in 
Files left in work directory after failure: dir, ufs.img


contrib/libxo/libxo/xo_buf.h has examples of non-zero offsets:

+/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22: runtime error: applying 
non-zero offset 4 to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22 in 
+/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44: runtime error: applying 
zero offset to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44 in 
+/usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29: runtime error: applying 
non-zero offset 4 to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29 in 

As does contrib/openzfs/module/nvpair/nvpair.c :

/usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: runtime 
error: applying non-zero offset 4 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49 in 


There is a:

+/usr/main-src/bin/sh/arith_yacc.c:193:10: runtime error: negation of 
-9223372036854775808 cannot be represented in type 'arith_t' (aka 'long'); cast 
to an unsigned type to negate this value to itself
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/bi

Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile

[Stefan Esser]

Am 07.01.22 um 12:49 schrieb Mark Millard:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
> 
> I see evidence of various examples of one type of undefined
> behavior: "applying zero offset to null pointer"
> 
> # more 
> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/usr.bin/sed/process.c:715:18 in 
> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> Fail: stderr not empty
> --- /dev/null   2022-01-07 10:29:57.182903000 +
> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr   2022-01-07 
> 10:29:57.17310 +
> @@ -0,0 +1,2 @@
> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
> offset to null pointer
> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /usr/main-src/lib/libc/stdio/fread.c:133:10 in 
> Files left in work directory after failure: mntpt, mounterr
> 
> 
> In general the lib/libc/stdio/fread.c:133:10 example seems to
> be in a place that would make it fairly common.

Interesting find:

while (resid > (r = fp->_r)) {
(void)memcpy((void *)p, (void *)fp->_p, (size_t)r);
fp->_p += r; /* line 133 */
/* fp->_r = 0 ... done in __srefill */
p += r;
resid -= r;

If fp->_p == NULL in line 133, then NULL has been passed as source address
in memcpy() in the line above, and I'd think that is undefined behavior,
even if a length of 0 is passed at the same time.

Maybe the code block quoted above (line 132 to 136) should be made wrapped
into "if (r > 0) {}"?

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile

[Mark Millard]

Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
after finding what to control to allow the build, I installed
it in a directory tree for chroot use and have
"kyua test -k /usr/tests/Kyuafile" running.

I see evidence of various examples of one type of undefined
behavior: "applying zero offset to null pointer"

# more /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt 
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/lib/libc/stdio/fread.c:133:10 in 
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/lib/libc/stdio/fread.c:133:10 in 
/usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero offset 
to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/usr.bin/sed/process.c:715:18 in 
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/lib/libc/stdio/fread.c:133:10 in 
Fail: stderr not empty
--- /dev/null   2022-01-07 10:29:57.182903000 +
+++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr   2022-01-07 
10:29:57.17310 +
@@ -0,0 +1,2 @@
+/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero 
offset to null pointer
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/usr/main-src/lib/libc/stdio/fread.c:133:10 in 
Files left in work directory after failure: mntpt, mounterr


In general the lib/libc/stdio/fread.c:133:10 example seems to
be in a place that would make it fairly common.

usr.bin/sed/process.c:715:18 is more limited: just sed use.

===
Mark Millard
marklmi at yahoo.com

FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile

[Mark Millard]

Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
after finding what to control to allow the build, I installed
it in a directory tree for chroot use and have
"kyua test -k /usr/tests/Kyuafile" running.

I see evidence of one AddressSanitizer report. (kyua is still
running.) The context is:

# more /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt 
Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ]
mount -t tmpfs -o size=10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt
Executing command [ touch a ]
Executing command [ rm a ]
Executing command [ dd if=/dev/zero of=a bs=1m count=15 ]
Executing command [ rm a ]

# more /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt 
=
==14384==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7fffa948 at pc 0x000801f38f5a bp 0x7fffa830 sp 0x7fffa828
WRITE of size 8 at 0x7fffa948 thread T0
#0 0x801f38f59 in strtoimax_l 
/usr/main-src/lib/libc/stdlib/strtoimax.c:148:11
#1 0x10de6c8 in strtoimax 
/usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:3441:18
#2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6
#3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7
#4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10
#5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10
#6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9
#7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8
#8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10
#9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8
#10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10
#11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16
#12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
#13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4
#14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4
#15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
#16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
#17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4
#18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
#19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
#20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3
#21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4
#22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c
#23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3

Address 0x7fffa948 is located in stack of thread T0 at offset 264 in frame
#0 0x801f387ff in strtoimax_l /usr/main-src/lib/libc/stdlib/strtoimax.c:58

  This frame has 1 object(s):
[32, 36) '__limit.i.i.i' <== Memory access at offset 264 overflows this 
variable
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow 
/usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l
Shadow bytes around the buggy address:
  0x44d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x44e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x44f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3
  0x4510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x4520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00
  0x4530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00
  0x4540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00
  0x4550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x4560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x4570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==14384==ABORTING
Files left in work directory after failure: mntpt, mounterr




===
Mark Millard
marklmi at yahoo.com

Re: Undeletable files after kyua test runs

[Gordon Bergling]

On Sat, Jul 04, 2020 at 10:02:45AM -0700, Enji Cooper wrote:
> > On Jul 4, 2020, at 8:59 AM, Enji Cooper  wrote:
> >> On Jul 2, 2020, at 7:57 PM, Enji Cooper  >> <mailto:yaneurab...@gmail.com>> wrote:
> >>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling  >>> <mailto:g...@freebsd.org>> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> I recently stumbled across undeletable files that are generated by kyua 
> >>> test runs,
> >>> for example
> >>> 
> >>> -rwxr-xr-x  1 root  wheel  0 May  9 13:10 
> >>> /tmp/kyua.aB4q62/8676/work/fileforaudit
> >>> 
> >>> I haven't yet identified the test that generate those files, but it is 
> >>> impossible
> >>> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, 
> >>> but 
> >>> on every boot the system argues that these file aren't deletable. 
> >>> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have 
> >>> looked for
> >>> any extend attributes, but I didn't find any.
> >>> 
> >>> Has anyone an idea how this is possible and may how these files can be 
> >>> deleted?
> >> 
> >> The issue is tests/sys/audit/file-attribute-modify.c , based on the file 
> >> present that can’t be deleted. Can you please provide more information 
> >> about the test run in a PR (I see how it can leave files behind, but I 
> >> want to make sure it is what I think it is, first)?
> > 
> > PR filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761 
> > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761> . Working on a 
> > CR.
> 
> Hi,
>   I just created the following CR: https://reviews.freebsd.org/D25561 
> <https://reviews.freebsd.org/D25561> and added the following related GitHub 
> issue to PR: https://github.com/jmmv/kyua/issues/142 
> <https://github.com/jmmv/kyua/issues/142> . This should be completed to avoid 
> issues like this in the future from occurring.
> Thank you for the report!
> -Enji

Hi Enji,

thanks for taking care of this issue and creating a PR. I didn't find the time 
in the last 3 days. Are you still need informationen about the kyua runs?

I usually just do a
# kyua test -k /usr/tests/Kyuafile
once in a while, which results for example in the following undeletable
files / directories.

-rwxr-xr-x  1 root  wheel  0 Jul  1 12:44 
/tmp/kyua.gv1loN/8718/work/fileforaudit
-rwxr-xr-x  1 root  wheel  0 Jul  5 08:50 
/tmp/kyua.FH0CAp/8718/work/fileforaudit

--Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Enji Cooper]

> On Jul 4, 2020, at 8:59 AM, Enji Cooper  wrote:
> 
>> 
>> On Jul 2, 2020, at 7:57 PM, Enji Cooper > <mailto:yaneurab...@gmail.com>> wrote:
>> 
>>> 
>>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling >> <mailto:g...@freebsd.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I recently stumbled across undeletable files that are generated by kyua 
>>> test runs,
>>> for example
>>> 
>>> -rwxr-xr-x  1 root  wheel  0 May  9 13:10 
>>> /tmp/kyua.aB4q62/8676/work/fileforaudit
>>> 
>>> I haven't yet identified the test that generate those files, but it is 
>>> impossible
>>> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but 
>>> on every boot the system argues that these file aren't deletable. 
>>> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have 
>>> looked for
>>> any extend attributes, but I didn't find any.
>>> 
>>> Has anyone an idea how this is possible and may how these files can be 
>>> deleted?
>> 
>> The issue is tests/sys/audit/file-attribute-modify.c , based on the file 
>> present that can’t be deleted. Can you please provide more information about 
>> the test run in a PR (I see how it can leave files behind, but I want to 
>> make sure it is what I think it is, first)?
> 
>   PR filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761 
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761> . Working on a CR.

Hi,
I just created the following CR: https://reviews.freebsd.org/D25561 
<https://reviews.freebsd.org/D25561> and added the following related GitHub 
issue to PR: https://github.com/jmmv/kyua/issues/142 
<https://github.com/jmmv/kyua/issues/142> . This should be completed to avoid 
issues like this in the future from occurring.
Thank you for the report!
-Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Enji Cooper]

> On Jul 2, 2020, at 7:57 PM, Enji Cooper  wrote:
> 
>> 
>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling  wrote:
>> 
>> Hi,
>> 
>> I recently stumbled across undeletable files that are generated by kyua test 
>> runs,
>> for example
>> 
>> -rwxr-xr-x  1 root  wheel  0 May  9 13:10 
>> /tmp/kyua.aB4q62/8676/work/fileforaudit
>> 
>> I haven't yet identified the test that generate those files, but it is 
>> impossible
>> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but 
>> on every boot the system argues that these file aren't deletable. 
>> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have 
>> looked for
>> any extend attributes, but I didn't find any.
>> 
>> Has anyone an idea how this is possible and may how these files can be 
>> deleted?
> 
> The issue is tests/sys/audit/file-attribute-modify.c , based on the file 
> present that can’t be deleted. Can you please provide more information about 
> the test run in a PR (I see how it can leave files behind, but I want to make 
> sure it is what I think it is, first)?

PR filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761> . Working on a CR.
Thanks,
-Enji

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Enji Cooper]

> On Jun 29, 2020, at 10:26 AM, Gordon Bergling  wrote:
> 
> Hi,
> 
> I recently stumbled across undeletable files that are generated by kyua test 
> runs,
> for example
> 
> -rwxr-xr-x  1 root  wheel  0 May  9 13:10 
> /tmp/kyua.aB4q62/8676/work/fileforaudit
> 
> I haven't yet identified the test that generate those files, but it is 
> impossible
> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but 
> on every boot the system argues that these file aren't deletable. 
> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have 
> looked for
> any extend attributes, but I didn't find any.
> 
> Has anyone an idea how this is possible and may how these files can be 
> deleted?

The issue is tests/sys/audit/file-attribute-modify.c , based on the file 
present that can’t be deleted. Can you please provide more information about 
the test run in a PR (I see how it can leave files behind, but I want to make 
sure it is what I think it is, first)?
Cheers,
-Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Gordon Bergling]

On Mon, Jun 29, 2020 at 01:18:12PM -0600, Ian Lepore wrote:
> On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > > g...@freebsd.org> wrote:
> > > > > > I recently stumbled across undeletable files that are
> > > > > > generated by kyua
> > > > > > test runs,
> > > > > > for example
> > > > > > 
> > > > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > > > 
> > > > > > I haven't yet identified the test that generate those files,
> > > > > > but it is
> > > > > > impossible
> > > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > > /etc/rc.conf, but
> > > > > > on every boot the system argues that these file aren't
> > > > > > deletable.
> > > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > > possible. I have
> > > > > > looked for
> > > > > > any extend attributes, but I didn't find any.
> > > > > > 
> > > > > > Has anyone an idea how this is possible and may how these
> > > > > > files can be
> > > > > > deleted?
> > > > > 
> > > > > Have you done 'ls -o' to check for flags like schg?
> > > > > --
> > > > > Kevin Oberman, Part time kid herder and retired Network
> > > > > Engineer
> > > > > E-mail: rkober...@gmail.com
> > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > > > 
> > > > Argh, I haven't thought about chflags for quite some time. The
> > > > chflags
> > > > bit was set and after an
> > > > 
> > > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> > > 
> > >^^Only files  ^^ meaningless when chflags is
> > > given ONLY files
> > > 
> > > You probably could of done:
> > > chflags -R 0 /tmp/
> > 
> > Okay, I am currently working on an update for clear_tmp_enable="YES"
> > to include
> > a check like this. I would think that an rc option like this should
> > delete 
> > everything in /tmp.
> > 
> 
> I disagree.  One of the few things those immutable flags are good for
> is protecting files from things like an rc script or other automation
> that deletes files.  Those flags are typically set and maintained by
> users and admins, and automation should not change them in order to
> delete files.
> 
> The real fix we need is for the kyua tests to properly clean up after
> themselves, including fixing the flags on temporary files created or
> used by the tests, and then deleting them.
> 
> -- Ian

A fix for the causing RC script was my first idea, but I had of course
the same idea that a kyua test could be fixed to not end in a state that
leads to file that has chflags set to a value that couldn't be deleted
by a job that is proposed to so.

I take this as a homework and look at the kyua scripts that created
those files.

--Gordon


signature.asc
Description: PGP signature

Re: Undeletable files after kyua test runs

[Michael Gmelin]

> On 29. Jun 2020, at 21:18, Ian Lepore  wrote:
> 
> On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
>> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
>>>> On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
>>>>> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
>>>>> g...@freebsd.org> wrote:
>>>>>> I recently stumbled across undeletable files that are
>>>>>> generated by kyua
>>>>>> test runs,
>>>>>> for example
>>>>>> 
>>>>>> -rwxr-xr-x  1 root  wheel  0 May  9 13:10
>>>>>> /tmp/kyua.aB4q62/8676/work/fileforaudit
>>>>>> 
>>>>>> I haven't yet identified the test that generate those files,
>>>>>> but it is
>>>>>> impossible
>>>>>> to delete them. I have clear_tmp_enable="YES" set in the
>>>>>> /etc/rc.conf, but
>>>>>> on every boot the system argues that these file aren't
>>>>>> deletable.
>>>>>> I tried to 'rm -rf' them by hand but, even this wasn't
>>>>>> possible. I have
>>>>>> looked for
>>>>>> any extend attributes, but I didn't find any.
>>>>>> 
>>>>>> Has anyone an idea how this is possible and may how these
>>>>>> files can be
>>>>>> deleted?
>>>>> 
>>>>> Have you done 'ls -o' to check for flags like schg?
>>>>> --
>>>>> Kevin Oberman, Part time kid herder and retired Network
>>>>> Engineer
>>>>> E-mail: rkober...@gmail.com
>>>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>>> 
>>>> Argh, I haven't thought about chflags for quite some time. The
>>>> chflags
>>>> bit was set and after an
>>>> 
>>>> # find /tmp/ -type f -exec chflags -R 0 {} \;
>>> 
>>>   ^^Only files  ^^ meaningless when chflags is
>>> given ONLY files
>>> 
>>> You probably could of done:
>>> chflags -R 0 /tmp/
>> 
>> Okay, I am currently working on an update for clear_tmp_enable="YES"
>> to include
>> a check like this. I would think that an rc option like this should
>> delete 
>> everything in /tmp.
>> 
> 
> I disagree.  One of the few things those immutable flags are good for
> is protecting files from things like an rc script or other automation
> that deletes files.  Those flags are typically set and maintained by
> users and admins, and automation should not change them in order to
> delete files.
> 
> The real fix we need is for the kyua tests to properly clean up after
> themselves, including fixing the flags on temporary files created or
> used by the tests, and then deleting them.
> 

+1, having a routine script remove schg automatically IMHO defeats the purpose 
of setting this flag.

Cheers,
Michael


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Ian Lepore]

On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > g...@freebsd.org> wrote:
> > > > > I recently stumbled across undeletable files that are
> > > > > generated by kyua
> > > > > test runs,
> > > > > for example
> > > > > 
> > > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > > 
> > > > > I haven't yet identified the test that generate those files,
> > > > > but it is
> > > > > impossible
> > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > /etc/rc.conf, but
> > > > > on every boot the system argues that these file aren't
> > > > > deletable.
> > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > possible. I have
> > > > > looked for
> > > > > any extend attributes, but I didn't find any.
> > > > > 
> > > > > Has anyone an idea how this is possible and may how these
> > > > > files can be
> > > > > deleted?
> > > > 
> > > > Have you done 'ls -o' to check for flags like schg?
> > > > --
> > > > Kevin Oberman, Part time kid herder and retired Network
> > > > Engineer
> > > > E-mail: rkober...@gmail.com
> > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > > 
> > > Argh, I haven't thought about chflags for quite some time. The
> > > chflags
> > > bit was set and after an
> > > 
> > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> > 
> >^^Only files  ^^ meaningless when chflags is
> > given ONLY files
> > 
> > You probably could of done:
> > chflags -R 0 /tmp/
> 
> Okay, I am currently working on an update for clear_tmp_enable="YES"
> to include
> a check like this. I would think that an rc option like this should
> delete 
> everything in /tmp.
> 

I disagree.  One of the few things those immutable flags are good for
is protecting files from things like an rc script or other automation
that deletes files.  Those flags are typically set and maintained by
users and admins, and automation should not change them in order to
delete files.

The real fix we need is for the kyua tests to properly clean up after
themselves, including fixing the flags on temporary files created or
used by the tests, and then deleting them.

-- Ian 

>  
> > > I was able to finally delete them.
> > > 
> > > Thanks for the fast respone,
> > > 
> > > Gordon
> 
> --Gordon
> ___
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Gordon Bergling]

On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > > > I recently stumbled across undeletable files that are generated by kyua
> > > > test runs,
> > > > for example
> > > >
> > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > >
> > > > I haven't yet identified the test that generate those files, but it is
> > > > impossible
> > > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, 
> > > > but
> > > > on every boot the system argues that these file aren't deletable.
> > > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > > looked for
> > > > any extend attributes, but I didn't find any.
> > > >
> > > > Has anyone an idea how this is possible and may how these files can be
> > > > deleted?
> > > 
> > > Have you done 'ls -o' to check for flags like schg?
> > > --
> > > Kevin Oberman, Part time kid herder and retired Network Engineer
> > > E-mail: rkober...@gmail.com
> > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > 
> > Argh, I haven't thought about chflags for quite some time. The chflags
> > bit was set and after an
> > 
> > # find /tmp/ -type f -exec chflags -R 0 {} \;
>^^Only files  ^^ meaningless when chflags is given 
> ONLY files
> 
> You probably could of done:
> chflags -R 0 /tmp/

Okay, I am currently working on an update for clear_tmp_enable="YES" to include
a check like this. I would think that an rc option like this should delete 
everything in /tmp.
 
> > I was able to finally delete them.
> > 
> > Thanks for the fast respone,
> > 
> > Gordon

--Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Rodney W. Grimes]

> Hi Kevin,
> Hi David,
> 
> On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > > I recently stumbled across undeletable files that are generated by kyua
> > > test runs,
> > > for example
> > >
> > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > >
> > > I haven't yet identified the test that generate those files, but it is
> > > impossible
> > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > > on every boot the system argues that these file aren't deletable.
> > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > looked for
> > > any extend attributes, but I didn't find any.
> > >
> > > Has anyone an idea how this is possible and may how these files can be
> > > deleted?
> > 
> > Have you done 'ls -o' to check for flags like schg?
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> Argh, I haven't thought about chflags for quite some time. The chflags
> bit was set and after an
> 
> # find /tmp/ -type f -exec chflags -R 0 {} \;
   ^^Only files  ^^ meaningless when chflags is given ONLY 
files

You probably could of done:
chflags -R 0 /tmp/

> 
> I was able to finally delete them.
> 
> Thanks for the fast respone,
> 
> Gordon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Gordon Bergling]

Hi Kevin,
Hi David,

On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > I recently stumbled across undeletable files that are generated by kyua
> > test runs,
> > for example
> >
> > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > /tmp/kyua.aB4q62/8676/work/fileforaudit
> >
> > I haven't yet identified the test that generate those files, but it is
> > impossible
> > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > on every boot the system argues that these file aren't deletable.
> > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > looked for
> > any extend attributes, but I didn't find any.
> >
> > Has anyone an idea how this is possible and may how these files can be
> > deleted?
> 
> Have you done 'ls -o' to check for flags like schg?
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Argh, I haven't thought about chflags for quite some time. The chflags
bit was set and after an

# find /tmp/ -type f -exec chflags -R 0 {} \;

I was able to finally delete them.

Thanks for the fast respone,

Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Kevin Oberman]

On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:

> Hi,
>
> I recently stumbled across undeletable files that are generated by kyua
> test runs,
> for example
>
> -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> /tmp/kyua.aB4q62/8676/work/fileforaudit
>
> I haven't yet identified the test that generate those files, but it is
> impossible
> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> on every boot the system argues that these file aren't deletable.
> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> looked for
> any extend attributes, but I didn't find any.
>
> Has anyone an idea how this is possible and may how these files can be
> deleted?
>
> --Gordon

Have you done 'ls -o' to check for flags like schg?
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Undeletable files after kyua test runs

[Gordon Bergling]

Hi,

I recently stumbled across undeletable files that are generated by kyua test 
runs,
for example

-rwxr-xr-x  1 root  wheel  0 May  9 13:10 
/tmp/kyua.aB4q62/8676/work/fileforaudit

I haven't yet identified the test that generate those files, but it is 
impossible
to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but 
on every boot the system argues that these file aren't deletable. 
I tried to 'rm -rf' them by hand but, even this wasn't possible. I have looked 
for
any extend attributes, but I didn't find any.

Has anyone an idea how this is possible and may how these files can be deleted?

--Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kyua test

[Kristof Provost]

On 31 Jan 2020, at 7:34, Clay Daniels wrote:
I've started running kyua test when I load the weekly current 
snapshot, and
I'm a little confused about if I should run kyua test as user or root. 
In
order to make the /usr/ports/devel/kyua port you need to be root and I 
have

just been doing the test as root, but I notice in the instructions I'm
using in the test(7) manpage it says:

$ kyua test -k /usr/tests/Kyuafile

Which suggested to me run as user with the $ (not #)

Of course, when I run it as user as I'm doing right now, it skips some
tests that are only for root. I guess I could use a little advice.

Some tests require root, some do not. It depends on what you want to 
test.
All tests that require root should announce this in their configuration, 
so running tests as a regular user should work, but you’ll end up with 
more skipped tests than if you run them as root.


I personally mostly care about network (and specifically pf) tests, so I 
tend to always run them as root. If you care about (e.g.) grep tests 
they should just work as a regular user.


Best regards,
Kristof
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kyua test

[Clay Daniels]

I've started running kyua test when I load the weekly current snapshot, and
I'm a little confused about if I should run kyua test as user or root. In
order to make the /usr/ports/devel/kyua port you need to be root and I have
just been doing the test as root, but I notice in the instructions I'm
using in the test(7) manpage it says:

$ kyua test -k /usr/tests/Kyuafile

Which suggested to me run as user with the $ (not #)

Of course, when I run it as user as I'm doing right now, it skips some
tests that are only for root. I guess I could use a little advice.

Clay
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Mark Millard]

On 2016-Jun-25, at 12:44 AM, Ngie Cooper  wrote:

> On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard  wrote:
>> On 2016-Jun-24, at 2:50 PM, Alan Somers  wrote:
>> 
>>> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring
>>> tests should all be fixed.  I opened PR 210329 for the
>>> usr.bin/lastcomm test.  I haven't investigated the others.
> 
> ...
> 
>> This time the totals were 15 broken (down from 24) and 41 failed (down
>> from 59).
>> 
>> My results this time were. . .
> 
> Hi Mark,
>Please file bugs for all of the individual component failures,
> e.g. lib/msun, and CC me on the bugs.
> Thanks,
> -Ngie

Done. I generally omitted the --verbose Metadata output. For a few there was a 
large block of Standard output or Standard error text that I omitted.

I was not sure of the intent but I put all the lib/msun "broken" items in one 
submittal, for example. Similarly for each of the other "broken" components.

Similarly for lib/msun "failed" items (a separate submittal). Similarly for 
each of the other "failed" components.



I noted explicitly in each submittal that I'd used -mcpu=cortex-a7 in my builds.

But in more detail:

A) buildworld and buildkernel had -march=armv7-a -mcpu=cortex-a7 both listed

B) ports builds (such as kyua itself) had -mcpu=cortex-a7 (but not 
-march=armv7-a)

This is because for ports I use options that do not complain for either clang 
3.8.0 or for fairly modern gcc and gcc does complain about specifying both 
-mcpu=armv7-a and -mcpu=cortex-a7. Even the "armv7-a" notation is from gcc 
rejecting armv7a but both clang and gcc accepting armv7-a notation.

(As I remember gcc uses -march=armv7-a where it conflicts with -mcpu=cortex-a7 
when both are listed but gcc does warn about conflict despite having a 
resolution rule.)

Other than the 11.0 -r302180 being more recent the "context details" in

https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061831.html

still apply. I did not repeat that information in the submittals but at least 
the src.conf and the like are available for reference.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Ngie Cooper]

On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard  wrote:
> On 2016-Jun-24, at 2:50 PM, Alan Somers  wrote:
>
>> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring
>> tests should all be fixed.  I opened PR 210329 for the
>> usr.bin/lastcomm test.  I haven't investigated the others.

...

> This time the totals were 15 broken (down from 24) and 41 failed (down
> from 59).
>
> My results this time were. . .

Hi Mark,
Please file bugs for all of the individual component failures,
e.g. lib/msun, and CC me on the bugs.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Mark Millard]

On 2016-Jun-24, at 2:50 PM, Alan Somers  wrote:

> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring
> tests should all be fixed.  I opened PR 210329 for the
> usr.bin/lastcomm test.  I haven't investigated the others.
> 
> -Alan

I updated to -r302180 and ran kyua again. It confirms the rpcbind, acl,
and bitstring items are gone from the broken and failed lists.

This time the totals were 15 broken (down from 24) and 41 failed (down
from 59).

My results this time were. . .

# kyua report --results-filter broken --results-file /usr/tests | more
===> Broken tests
lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.094s]
lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.097s]
lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.097s]
lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.099s]
lib/msun/fma_test:main  ->  broken: Received signal 6  [1.114s]
lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.118s]
lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.114s]
lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.096s]
lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.096s]
lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.096s]
lib/msun/rem_test:main  ->  broken: Received signal 6  [1.091s]
lib/msun/trig_test:main  ->  broken: Received signal 6  [1.094s]
sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
executed tests  [0.479s]
sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out  
[1200.089s]
sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
[600.041s]
===> Summary
Results read from /root/.kyua/store/results.usr_tests.20160625-012941-048472.db
Test cases: 5700 total, 54 skipped, 20 expected failures, 15 broken, 41 failed
Total time: 9093.092s

# kyua report --results-filter failed --results-file /usr/tests | more
===> Failed tests
lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
/usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, , 
sizeof(st1)) == 0 not met  [0.028s]
lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok exit 
code, but this is not allowed  [0.159s]
lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok exit 
code, but this is not allowed  [0.152s]
lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output of 
the test for details  [0.150s]
lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output of 
the test for details  [0.149s]
lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output of 
the test for details  [0.152s]
lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok exit 
code, but this is not allowed  [0.159s]
lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output of 
the test for details  [0.161s]
lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output of 
the test for details  [0.143s]
lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output of 
the test for details  [0.143s]
lib/libc/ssp/ssp_test:stpcpy  ->  failed: atf-check failed; see the output of 
the test for details  [0.146s]
lib/libc/ssp/ssp_test:stpncpy  ->  failed: atf-check failed; see the output of 
the test for details  [0.149s]
lib/libc/ssp/ssp_test:strcat  ->  failed: atf-check failed; see the output of 
the test for details  [0.148s]
lib/libc/ssp/ssp_test:strcpy  ->  failed: atf-check failed; see the output of 
the test for details  [0.152s]
lib/libc/ssp/ssp_test:strncat  ->  failed: atf-check failed; see the output of 
the test for details  [0.143s]
lib/libc/ssp/ssp_test:strncpy  ->  failed: atf-check failed; see the output of 
the test for details  [0.147s]
lib/libc/ssp/ssp_test:vsnprintf  ->  failed: atf-check failed; see the output 
of the test for details  [0.145s]
lib/libc/ssp/ssp_test:vsprintf  ->  failed: atf-check failed; see the output of 
the test for details  [0.146s]
lib/libc/stdio/printbasic_test:int_within_limits  ->  failed: printf("%tu", 
(size_t)-1) ==> [18446744073709551615], expected [4294967295]<>  
[0.029s]
lib/libc/stdio/scanfloat_test:infinities_and_nans  ->  failed: 
/usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: fetestexcept(FE_INVALID) == 
0 not met  [0.032
s]
lib/libc/sys/mincore_test:mincore_resid  ->  failed: 
/usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: 
check_residency(addr, npgs) == 0 not met  [0.04
1s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  failed: 
/usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: 
check_residency(addr, npgs) == 0 not met  [0.0
32s]
lib/libc/tls/tls_dynamic_test:t_tls_dynamic  ->  failed: 15 checks failed; see 
output for more details  [0.037s]
lib/libproc/proc_test:symbol_lookup  ->  failed: 
/usr/src/lib/libproc/tests/proc_test.c:116: state != PS_STOP: process has state 
4  [0.180s]
lib/libxo/functional_test:test_02__E  -> 

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Alan Somers]

>> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net
>> > > wrote:
>> > > With the newly less strict alignment requirements "kyua test -k
>> > > /usr/tests/Kyuafile" runs to completion, unlike before.
>> > >
>> > > > ===> Summary
>> > > > Results read from /root/.kyua/store/results.usr_tests.20160613
>> > > > -080302-120731.db
>> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24
>> > > > broken, 59 failed
>> > > > Total time: 8723.243s
>> > >
>> > >
>> > > I only list the one line summaries below. Then I list various
>> > > context details.
>> > >
>> > > > ===> Broken tests
>> > > > lib/msun/cexp_test:main  ->  broken: Received signal 6
>> > > >  [1.054s]
>> > > > lib/msun/ctrig_test:main  ->  broken: Received signal 6
>> > > >  [1.074s]
>> > > > lib/msun/exponential_test:main  ->  broken: Received signal 6
>> > > >  [1.045s]
>> > > > lib/msun/fenv_test:main  ->  broken: Received signal 6
>> > > >  [1.048s]
>> > > > lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>> > > > lib/msun/invctrig_test:main  ->  broken: Received signal 6
>> > > >  [1.091s]
>> > > > lib/msun/invtrig_test:main  ->  broken: Received signal 6
>> > > >  [1.086s]
>> > > > lib/msun/logarithm_test:main  ->  broken: Received signal 6
>> > > >  [1.054s]
>> > > > lib/msun/lrint_test:main  ->  broken: Received signal 6
>> > > >  [1.069s]
>> > > > lib/msun/nearbyint_test:main  ->  broken: Received signal 6
>> > > >  [1.066s]
>> > > > lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>> > > > lib/msun/trig_test:main  ->  broken: Received signal 6
>> > > >  [1.070s]
>> > > > sbin/growfs/legacy_test:main  ->  broken: Reported plan differs
>> > > > from actual executed tests  [0.459s]
>> > > > sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test
>> > > > case timed out  [1200.082s]
>> > > > sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test
>> > > > case timed out  [600.138s]
>> > > > sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case
>> > > > timed out  [600.044s]
>> > > > sys/sys/bitstring_test:bit_clear  ->  broken: Test case body
>> > > > timed out  [300.032s]
>> > > > sys/sys/bitstring_test:bit_count  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.080s]
>> > > > sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.077s]
>> > > > sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.081s]
>> > > > sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.082s]
>> > > > sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.077s]
>> > > > sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.083s]
>> > > > sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit;
>> > > > test case received signal 11 (core dumped)  [1.079s]
>> > >
>> > >
>> > > > ===> Failed tests
>> > > > lib/libc/c063/fstatat_test:fstatat_fd  ->  failed:
>> > > > /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74:
>> > > > memcmp(, , sizeof(st1)) == 0 not met  [0.
>> > > > 027s]
>> > > > lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4
>> > > > ->  failed: /usr/src/lib/libc/tests/nss/gethostby_test.c:1335:
>> > > > run_tests(_hostlist_file, _snapshot
>> > > > _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met
>> > > >  [15.315s]
>> > > > lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body
>> > > > returned a non-ok exit code, but this is not allowed  [0.153s]
>> > > > lib/libc/ssp/ssp_

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Ian Lepore]

On Mon, 2016-06-13 at 11:04 -0700, Conrad Meyer wrote:
> I expect it's because:
> 
> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
> unsigned long))

This might result in allocating too-few bytes, but that's something
you'd only notice if you have something like valgrind watching out for
accesses beyond the allocated size.

> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
> 'unsigned long' sized or aligned).
> 3. Various bit_* functions access the result as if it's an array of
> 'unsigned long', when it was allocated as a single-byte array (no
> ulong alignment or size).

malloc and related functions (including calloc) always return memory
"...suitably aligned for storage of any type of object."  Last time I
checked that basically meant all allocations, even a single byte, are
aligned on a 16-byte boundary on arm.

> 4. ARM isn't as happy about unaligned accesses as x86.
> 

That's mostly not the case anymore.  Using load/store-doubleword or
load/store-multiple instructions requires 4-byte-aligned values (not a
typo: doubleword access requires word alignment).  Everything smaller
than doubleword access in userland these days can be unaligned.  The
optimizer can combine adjacent 32-bit accesses into doubleword
-instruction accesses, leading to alignment faults with unaligned data,
but that shouldn't be the case here because malloc'd memory is aligned.

-- Ian

> I'd make the following change (needs sys/param.h, not compile tested)
> and see if it fixes it:
> 
> --- sys/bitstring.h (revision 301805)
> +++ sys/bitstring.h (working copy)
> @@ -119,7 +119,8 @@
>  static inline bitstr_t *
>  bit_alloc(int _nbits)
>  {
> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
> +   return (calloc(howmany(bitstr_size(_nbits),
> sizeof(bitstr_t)),
> +   sizeof(bitstr_t)));
>  }
>  #endif
> 
> 
> 
> 
> 
> 
> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org>
> wrote:
> > Please open a bug for the bitstring test failures and assign it to
> > me.
> > Also, since I don't have any arm hardware, please provide
> > instructions
> > on how to run this code in a VM, or where I can get access to the
> > hardware.
> > 
> > -Alan
> > 
> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net
> > > wrote:
> > > With the newly less strict alignment requirements "kyua test -k
> > > /usr/tests/Kyuafile" runs to completion, unlike before.
> > > 
> > > > ===> Summary
> > > > Results read from /root/.kyua/store/results.usr_tests.20160613
> > > > -080302-120731.db
> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24
> > > > broken, 59 failed
> > > > Total time: 8723.243s
> > > 
> > > 
> > > I only list the one line summaries below. Then I list various
> > > context details.
> > > 
> > > > ===> Broken tests
> > > > lib/msun/cexp_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/ctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.074s]
> > > > lib/msun/exponential_test:main  ->  broken: Received signal 6 
> > > >  [1.045s]
> > > > lib/msun/fenv_test:main  ->  broken: Received signal 6 
> > > >  [1.048s]
> > > > lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
> > > > lib/msun/invctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.091s]
> > > > lib/msun/invtrig_test:main  ->  broken: Received signal 6 
> > > >  [1.086s]
> > > > lib/msun/logarithm_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/lrint_test:main  ->  broken: Received signal 6 
> > > >  [1.069s]
> > > > lib/msun/nearbyint_test:main  ->  broken: Received signal 6 
> > > >  [1.066s]
> > > > lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
> > > > lib/msun/trig_test:main  ->  broken: Received signal 6 
> > > >  [1.070s]
> > > > sbin/growfs/legacy_test:main  ->  broken: Reported plan differs
> > > > from actual executed tests  [0.459s]
> > > > sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test
> > > > case timed out  [1200.082s]
> > > > sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test
> > > > case timed out  [600.138s]
> > > 

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Conrad Meyer]

I expect it's because:

1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
unsigned long))
2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
(an array of nmemb=bitstr_size() size=bytes, doesn't have to be
'unsigned long' sized or aligned).
3. Various bit_* functions access the result as if it's an array of
'unsigned long', when it was allocated as a single-byte array (no
ulong alignment or size).
4. ARM isn't as happy about unaligned accesses as x86.

I'd make the following change (needs sys/param.h, not compile tested)
and see if it fixes it:

--- sys/bitstring.h (revision 301805)
+++ sys/bitstring.h (working copy)
@@ -119,7 +119,8 @@
 static inline bitstr_t *
 bit_alloc(int _nbits)
 {
-   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
+   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
+   sizeof(bitstr_t)));
 }
 #endif






On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
> Please open a bug for the bitstring test failures and assign it to me.
> Also, since I don't have any arm hardware, please provide instructions
> on how to run this code in a VM, or where I can get access to the
> hardware.
>
> -Alan
>
> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>> With the newly less strict alignment requirements "kyua test -k 
>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>
>>> ===> Summary
>>> Results read from 
>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>> failed
>>> Total time: 8723.243s
>>
>>
>> I only list the one line summaries below. Then I list various context 
>> details.
>>
>>> ===> Broken tests
>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>>> executed tests  [0.459s]
>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>> out  [1200.082s]
>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>> out  [600.138s]
>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>> [600.044s]
>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>> [300.032s]
>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.080s]
>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.081s]
>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.082s]
>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.083s]
>>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.079s]
>>
>>
>>> ===> Failed tests
>>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>>> , sizeof(st1)) == 0 not met  [0.
>>> 027s]
>>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: 
>>> run_t

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Alan Somers]

This isn't an ABI issue.  Since there's no dynamic library, there's no
ABI to break except for weird circumstances like writing the in-memory
representation of a bitstring to a file, rebuilding world, and reading
that file back in.  The ATF tests aren't doing anything like that.

On Mon, Jun 13, 2016 at 12:05 PM, Conrad Meyer <c...@freebsd.org> wrote:
> FYI, this implies the ulong-accessed bitstring change is ABI-breaking
> for ARM userspace and maybe shouldn't go to stable/10.
>
> Best,
> Conrad
>
> On Mon, Jun 13, 2016 at 11:04 AM, Conrad Meyer <c...@freebsd.org> wrote:
>> I expect it's because:
>>
>> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
>> unsigned long))
>> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
>> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
>> 'unsigned long' sized or aligned).
>> 3. Various bit_* functions access the result as if it's an array of
>> 'unsigned long', when it was allocated as a single-byte array (no
>> ulong alignment or size).
>> 4. ARM isn't as happy about unaligned accesses as x86.
>>
>> I'd make the following change (needs sys/param.h, not compile tested)
>> and see if it fixes it:
>>
>> --- sys/bitstring.h (revision 301805)
>> +++ sys/bitstring.h (working copy)
>> @@ -119,7 +119,8 @@
>>  static inline bitstr_t *
>>  bit_alloc(int _nbits)
>>  {
>> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
>> +   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
>> +   sizeof(bitstr_t)));
>>  }
>>  #endif
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
>>> Please open a bug for the bitstring test failures and assign it to me.
>>> Also, since I don't have any arm hardware, please provide instructions
>>> on how to run this code in a VM, or where I can get access to the
>>> hardware.
>>>
>>> -Alan
>>>
>>> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>>>> With the newly less strict alignment requirements "kyua test -k 
>>>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>>>
>>>>> ===> Summary
>>>>> Results read from 
>>>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>>>> failed
>>>>> Total time: 8723.243s
>>>>
>>>>
>>>> I only list the one line summaries below. Then I list various context 
>>>> details.
>>>>
>>>>> ===> Broken tests
>>>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from 
>>>>> actual executed tests  [0.459s]
>>>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>>>> out  [1200.082s]
>>>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>>>> out  [600.138s]
>>>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>>>> [600.044s]
>>>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>>>> [300.032s]
>>>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>>>> received signal 11 (core dumped)  [1.080s]
>>>>> sys/sys/bitstrin

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Mark Millard]

[I've added a list of core files generated and a few other notes.]

On 2016-Jun-13, at 10:29 AM, Mark Millard  wrote:

> With the newly less strict alignment requirements "kyua test -k 
> /usr/tests/Kyuafile" runs to completion, unlike before.
> 
>> ===> Summary
>> Results read from 
>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>> failed
>> Total time: 8723.243s
> 
> 
> I only list the one line summaries below. Then I list various context details.
> 
>> ===> Broken tests
>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>> executed tests  [0.459s]
>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out 
>>  [1200.082s]
>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out 
>>  [600.138s]
>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>> [600.044s]
>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>> [300.032s]
>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.080s]
>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.081s]
>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.082s]
>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.083s]
>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.079s]
> 
> 
>> ===> Failed tests
>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>> , sizeof(st1)) == 0 not met  [0.
>> 027s]
>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
>> _snapshot
>> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
>> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.153s]
>> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.158s]
>> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.148s]
>> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.154s]
>> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.155s]
>> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:stpcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Mark Millard]

On 2016-Jun-13, at 10:49 AM, Alan Somers  wrote:

> Please open a bug for the bitstring test failures and assign it to me.
> Also, since I don't have any arm hardware, please provide instructions
> on how to run this code in a VM, or where I can get access to the
> hardware.
> 
> -Alan

I have created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210260 for the 
broken kyua bitstring tests.

I do not seem to have any control over the Assignee. (I  have no FreeBSD status 
of any kind so this is not surprising to me.)

I've never used QEMU or any arm-hardware based virtual machines. I've only used 
an rpi2 for armv6. So far the only VM's I've used are for amd64 running on 
amd64 hardware --and I run those under Mac OS X (VirtualBox, Parallels).

I'm not set up to give remote access to the rpi2 that I'm using.

So at this point I'm not much help for those arm-specific instructions that you 
asked for. Sorry.

===
Mark Millard
markmi at dsl-only.net

> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard  wrote:
>> With the newly less strict alignment requirements "kyua test -k 
>> /usr/tests/Kyuafile" runs to completion, unlike before.
>> 
>>> ===> Summary
>>> Results read from 
>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>> failed
>>> Total time: 8723.243s
>> 
>> 
>> I only list the one line summaries below. Then I list various context 
>> details.
>> 
>>> ===> Broken tests
. . .
>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>> [300.032s]
>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.080s]
>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.081s]
>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.082s]
>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.083s]
>>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.079s]
>> 
. . .
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Conrad Meyer]

FYI, this implies the ulong-accessed bitstring change is ABI-breaking
for ARM userspace and maybe shouldn't go to stable/10.

Best,
Conrad

On Mon, Jun 13, 2016 at 11:04 AM, Conrad Meyer <c...@freebsd.org> wrote:
> I expect it's because:
>
> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
> unsigned long))
> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
> 'unsigned long' sized or aligned).
> 3. Various bit_* functions access the result as if it's an array of
> 'unsigned long', when it was allocated as a single-byte array (no
> ulong alignment or size).
> 4. ARM isn't as happy about unaligned accesses as x86.
>
> I'd make the following change (needs sys/param.h, not compile tested)
> and see if it fixes it:
>
> --- sys/bitstring.h (revision 301805)
> +++ sys/bitstring.h (working copy)
> @@ -119,7 +119,8 @@
>  static inline bitstr_t *
>  bit_alloc(int _nbits)
>  {
> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
> +   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
> +   sizeof(bitstr_t)));
>  }
>  #endif
>
>
>
>
>
>
> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
>> Please open a bug for the bitstring test failures and assign it to me.
>> Also, since I don't have any arm hardware, please provide instructions
>> on how to run this code in a VM, or where I can get access to the
>> hardware.
>>
>> -Alan
>>
>> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>>> With the newly less strict alignment requirements "kyua test -k 
>>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>>
>>>> ===> Summary
>>>> Results read from 
>>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>>> failed
>>>> Total time: 8723.243s
>>>
>>>
>>> I only list the one line summaries below. Then I list various context 
>>> details.
>>>
>>>> ===> Broken tests
>>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from 
>>>> actual executed tests  [0.459s]
>>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>>> out  [1200.082s]
>>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>>> out  [600.138s]
>>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>>> [600.044s]
>>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>>> [300.032s]
>>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.080s]
>>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.077s]
>>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.081s]
>>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.082s]
>>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.077s]
>>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>>> received signal 11 (core d

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Alan Somers]

Please open a bug for the bitstring test failures and assign it to me.
Also, since I don't have any arm hardware, please provide instructions
on how to run this code in a VM, or where I can get access to the
hardware.

-Alan

On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
> With the newly less strict alignment requirements "kyua test -k 
> /usr/tests/Kyuafile" runs to completion, unlike before.
>
>> ===> Summary
>> Results read from 
>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>> failed
>> Total time: 8723.243s
>
>
> I only list the one line summaries below. Then I list various context details.
>
>> ===> Broken tests
>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>> executed tests  [0.459s]
>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out 
>>  [1200.082s]
>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out 
>>  [600.138s]
>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>> [600.044s]
>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>> [300.032s]
>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.080s]
>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.081s]
>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.082s]
>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.083s]
>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.079s]
>
>
>> ===> Failed tests
>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>> , sizeof(st1)) == 0 not met  [0.
>> 027s]
>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
>> _snapshot
>> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
>> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.153s]
>> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.158s]
>> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.148s]
>> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.154s]
>> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.155s]
>> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
>> 

11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Mark Millard]

With the newly less strict alignment requirements "kyua test -k 
/usr/tests/Kyuafile" runs to completion, unlike before.

> ===> Summary
> Results read from 
> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 failed
> Total time: 8723.243s


I only list the one line summaries below. Then I list various context details.

> ===> Broken tests
> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
> executed tests  [0.459s]
> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out  
> [1200.082s]
> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out  
> [600.138s]
> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
> [600.044s]
> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
> [300.032s]
> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.080s]
> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.077s]
> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.081s]
> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.082s]
> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.077s]
> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.083s]
> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.079s]


> ===> Failed tests
> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
> , sizeof(st1)) == 0 not met  [0.
> 027s]
> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
> _snapshot
> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
> exit code, but this is not allowed  [0.153s]
> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok exit 
> code, but this is not allowed  [0.158s]
> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.148s]
> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
> of the test for details  [0.147s]
> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok exit 
> code, but this is not allowed  [0.154s]
> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
> of the test for details  [0.155s]
> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.149s]
> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.149s]
> lib/libc/ssp/ssp_test:stpcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.149s]
> lib/libc/ssp/ssp_test:stpncpy  ->  failed: atf-check failed; see the output 
> of the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strcat  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strncat  ->  failed: atf-check failed; see the output 
> of the test for detail