Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Thursday, July 9, 2015, Garrett Wollman wrote: > In article > >, > oliver.pin...@hardenedbsd.org writes: > > >Btw, I have found this is atf's documantation: > >atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the > >specific test case could "fail" / or expect to coredump. > > No. > > I'm not sure why people are having trouble understanding this. > > The test in question is not valid C. It is entirely erroneous, and > should be deleted. Merely computing the value "(void *)-1" is allowed > to perform LITERALLY ANY ACTION AT ALL, including turning your > computer into a frog. The compiler is free to implement this as a > call to abort() if it chooses. Testing this is nonsensical. > > -GAWollman > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > +1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article , oliver.pin...@hardenedbsd.org writes: >Btw, I have found this is atf's documantation: >atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the >specific test case could "fail" / or expect to coredump. No. I'm not sure why people are having trouble understanding this. The test in question is not valid C. It is entirely erroneous, and should be deleted. Merely computing the value "(void *)-1" is allowed to perform LITERALLY ANY ACTION AT ALL, including turning your computer into a frog. The compiler is free to implement this as a call to abort() if it chooses. Testing this is nonsensical. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 7/9/15, NGie Cooper wrote: > On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov > wrote: >> On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote: >>> I'm not sure if we want to explicitly document the conditions under >>> which >>> gettimeofday() (or clock_gettime()) are implemented in userland vs >>> syscalls >>> because that is guaranteed to get stale over time. How about stating >>> that >> Of course, we don't. There is no guarantee that the set of conditions >> is stable even on the stable branch. >> >>> these functions are implemented as syscalls only if the AT_TIMEKEEP >>> value >>> reported by "procstat -x" is NULL. >> Mere presence of AT_TIMEKEEP does not imply the use of the fast path. >> E.g. the fast path can be disabled dynamically, or timecounter could be >> changed, or libc might be of the wrong version. My imagination stops >> there. >> >> IMO the point of this discussion is to note that test suite tests useless > > useless -> inapplicable Btw, I have found this is atf's documantation: atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the specific test case could "fail" / or expect to coredump. > >> things. > > things. -> things [for FreeBSD]. > >> If somebody run the test suite for libc, she would immediately note >> another failing test for the stack protector, which is similar to the >> gettimeofday nonsense. > > Perhaps, but that's assuming that NetBSD implemented gettimeofday in > userland, which is doesn't. > > I agree that this is less applicable for FreeBSD than NetBSD. Please > keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD. > Peter Holm and I tried our best to vet out the issues with the test > suite before integrating it in, but there might be issues due to > implementation discrepancies between FreeBSD and NetBSD. > > Thanks, > -NGie > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 9 Jul 2015, at 10:17, NGie Cooper wrote: > > I agree that this is less applicable for FreeBSD than NetBSD. Please > keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD. > Peter Holm and I tried our best to vet out the issues with the test > suite before integrating it in, but there might be issues due to > implementation discrepancies between FreeBSD and NetBSD. The high-level question is whether these are conformance tests (in which case they should be checking for specified behaviour) or regression tests (in which case they should be checking for known implementation details, but should explicitly document what those are). When the gettimeofday implementation changed, it would have been nice to get two results: - No conformance tests failed, change is still a valid implementation of POSIX gettimeofday() - One regression test failed. This test is assuming that gettimeofday() is a system call and so should be marked as an expected failure. Unfortunately, the test suite currently conflates the two. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov wrote: > On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote: >> I'm not sure if we want to explicitly document the conditions under which >> gettimeofday() (or clock_gettime()) are implemented in userland vs syscalls >> because that is guaranteed to get stale over time. How about stating that > Of course, we don't. There is no guarantee that the set of conditions > is stable even on the stable branch. > >> these functions are implemented as syscalls only if the AT_TIMEKEEP value >> reported by "procstat -x" is NULL. > Mere presence of AT_TIMEKEEP does not imply the use of the fast path. > E.g. the fast path can be disabled dynamically, or timecounter could be > changed, or libc might be of the wrong version. My imagination stops > there. > > IMO the point of this discussion is to note that test suite tests useless useless -> inapplicable > things. things. -> things [for FreeBSD]. > If somebody run the test suite for libc, she would immediately note > another failing test for the stack protector, which is similar to the > gettimeofday nonsense. Perhaps, but that's assuming that NetBSD implemented gettimeofday in userland, which is doesn't. I agree that this is less applicable for FreeBSD than NetBSD. Please keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD. Peter Holm and I tried our best to vet out the issues with the test suite before integrating it in, but there might be issues due to implementation discrepancies between FreeBSD and NetBSD. Thanks, -NGie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote: > I'm not sure if we want to explicitly document the conditions under which > gettimeofday() (or clock_gettime()) are implemented in userland vs syscalls > because that is guaranteed to get stale over time. How about stating that Of course, we don't. There is no guarantee that the set of conditions is stable even on the stable branch. > these functions are implemented as syscalls only if the AT_TIMEKEEP value > reported by "procstat -x" is NULL. Mere presence of AT_TIMEKEEP does not imply the use of the fast path. E.g. the fast path can be disabled dynamically, or timecounter could be changed, or libc might be of the wrong version. My imagination stops there. IMO the point of this discussion is to note that test suite tests useless things. If somebody run the test suite for libc, she would immediately note another failing test for the stack protector, which is similar to the gettimeofday nonsense. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 2015-Jul-08 12:22:03 -0700, Garrett Cooper wrote: >On Jul 8, 2015, at 12:17, Doug Rabson wrote: > >> As far as I can tell, POSIX doesn't require either EFAULT or any other >> behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf >> just says, "No errors are defined". Our man page is wrong and any real >> program which relies on gettimeofday not faulting when given bad inputs is >> broken. > >I would suggest the following: >1. Document behavior in NOTES about gettimeofday returning EFAULT with the >specific scenarios kib mentioned, segfaulting otherwise (wordsmithing the >actual info of course). Otherwise, it might confuse people who look at the >manpage later. I would suggest adding a comment to intro(2) noting that not all functions listed in section 2 are necessarily system calls and may report error conditions (or maybe "perform argument validation") differently when implemented in userland. Note that the issues with gettimeofday() also apply to clock_gettime(). I'm not sure if we want to explicitly document the conditions under which gettimeofday() (or clock_gettime()) are implemented in userland vs syscalls because that is guaranteed to get stale over time. How about stating that these functions are implemented as syscalls only if the AT_TIMEKEEP value reported by "procstat -x" is NULL. -- Peter Jeremy pgpNkOswpFC0C.pgp Description: PGP signature
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article <559d8e55.9050...@freebsd.org> a...@freebsd.org writes: >I am not suggesting this but if our man pages used all capitals to signify >important auxiliary verbs then the ERRORS sections would read as > The following error codes MAY be set in errno: >Perhaps in that case it would be more clear how 'MAY' differs from 'SHOULD' and >'MUST'. >Of course, the manual pages seem to be too sloppy in this respect. No, it's just the standard meaning of "may" as defined in the POSIX standard. ISO standards in general use "shall" for mandatory behavior and "may" for optional behavior. (For every occurrence of the word "shall" in the POSIX standard, there should be a conformance test[1]; "may" covers behavior where implementations are allowed to differ with no conformance distinction being made.) In the specific case of library interfaces, "may fail and set the following code in errno" is slightly more restrictive: the implementation is required to raise that error if the associated condition is detected, but it is not required to detect that condition even if it is present, and it may indicate some other error condition that is present and detectable. -GAWollman [1] Technically, this applies only to "shall" where the subject is the implementation. POSIX also includes "shall" requirements on applications, which obviously can't be tested. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 08/07/2015 22:22, Garrett Cooper wrote: > On Jul 8, 2015, at 12:17, Doug Rabson wrote: > >> As far as I can tell, POSIX doesn't require either EFAULT or any other >> behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf >> just says, "No errors are defined". Our man page is wrong and any real >> program which relies on gettimeofday not faulting when given bad inputs is >> broken. > > I would suggest the following: 1. Document behavior in NOTES about > gettimeofday returning EFAULT with the specific scenarios kib mentioned, > segfaulting otherwise (wordsmithing the actual info of course). Otherwise, it > might confuse people who look at the manpage later. 2. I’ll add a `#ifdef > __FreeBSD__` to the testcase which will then skip it, because it’s easier to > do that then test undefined behavior that only makes sense on NetBSD. I am not suggesting this but if our man pages used all capitals to signify important auxiliary verbs then the ERRORS sections would read as The following error codes MAY be set in errno: Perhaps in that case it would be more clear how 'MAY' differs from 'SHOULD' and 'MUST'. Of course, the manual pages seem to be too sloppy in this respect. Reference: https://www.ietf.org/rfc/rfc2119.txt -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Jul 8, 2015, at 12:17, Doug Rabson wrote: > As far as I can tell, POSIX doesn't require either EFAULT or any other > behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf > just says, "No errors are defined". Our man page is wrong and any real > program which relies on gettimeofday not faulting when given bad inputs is > broken. I would suggest the following: 1. Document behavior in NOTES about gettimeofday returning EFAULT with the specific scenarios kib mentioned, segfaulting otherwise (wordsmithing the actual info of course). Otherwise, it might confuse people who look at the manpage later. 2. I’ll add a `#ifdef __FreeBSD__` to the testcase which will then skip it, because it’s easier to do that then test undefined behavior that only makes sense on NetBSD. Thanks! -NGie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
As far as I can tell, POSIX doesn't require either EFAULT or any other behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf just says, "No errors are defined". Our man page is wrong and any real program which relies on gettimeofday not faulting when given bad inputs is broken. On 8 July 2015 at 17:16, Jamie Landeg-Jones wrote: > Oliver Pinter wrote: > > > On 7/8/15, O'Connor, Daniel wrote: > > > > > > In defence of the test, the man page says it can return EFAULT. > > > > That's fine, but why changed the behaviour since 2015. May 27.? I have > > an older FreeBSD/HardenedBSD install, where this test passing. See > > some previous email in this thread. > > That's why it's called 'undefined' :-) > > Pedantically, being 'undefined', it's behaviour hasn't changed at all! > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: > > > > In defence of the test, the man page says it can return EFAULT. > > That's fine, but why changed the behaviour since 2015. May 27.? I have > an older FreeBSD/HardenedBSD install, where this test passing. See > some previous email in this thread. That's why it's called 'undefined' :-) Pedantically, being 'undefined', it's behaviour hasn't changed at all! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Wed, Jul 08, 2015 at 12:36:08PM +0200, Oliver Pinter wrote: > Changing to HPET solves the problem: No, it does not solve the problem, it only hides it. The solution is to remove the test. Or, if so inclined, only run the test when gettimeofday(2) is implemented by a syscall. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 7/8/15, Konstantin Belousov wrote: > On Wed, Jul 08, 2015 at 11:53:39AM +0200, Oliver Pinter wrote: >> On 7/8/15, O'Connor, Daniel wrote: >> > >> >> On 8 Jul 2015, at 08:11, Garrett Wollman >> >> >> >> wrote: >> >> Perhaps the test was (erroneously) written to assume that >> >> gettimeofday() was a system call, and could therefore detect invalid >> >> pointers and return [EFAULT]. This has not been the case for some >> >> time. (In HEAD, not since r237434, which is three years ago.) >> > >> > In defence of the test, the man page says it can return EFAULT. >> >> That's fine, but why changed the behaviour since 2015. May 27.? I have >> an older FreeBSD/HardenedBSD install, where this test passing. See >> some previous email in this thread. > Current implemention detail is that gettimeofday(-1) causes SIGSEGV > if kern.timecounter.hardware=TSC-low and kern.timecounter.fast_gettime=1. > If you timecounter changed for whatever reason, the result of that > call would fluctuate between EFAULT and signal. Thanks Konstantin! Yes, the systems defaults to TSC-low. root@nyi-01 ~# sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC-low root@nyi-01 ~# sysctl kern.timecounter.fast_gettime kern.timecounter.fast_gettime: 1 root@nyi-01 ~# sysctl kern.timecounter.choice kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) Changing to HPET solves the problem: root@nyi-01 ~# sysctl kern.timecounter.hardware=HPET kern.timecounter.hardware: TSC-low -> HPET root@nyi-01 ~# cd /usr/tests/lib/libc/sys root@nyi-01 sys# kyua test gettimeofday_test gettimeofday_test:gettimeofday_err -> passed [0.011s] gettimeofday_test:gettimeofday_mono -> passed [0.012s] Results file id is usr_tests_lib_libc_sys.20150708-103338-126124 Results saved to /root/.kyua/store/results.usr_tests_lib_libc_sys.20150708-103338-126124.db 2/2 passed (0 failed) > > This is not the only test in the test set which checks something that > cannot be reasonably explained. > >> >> > >> > (IMO the man page and test should change..) >> > >> > -- >> > Daniel O'Connor >> > "The nice thing about standards is that there >> > are so many of them to choose from." >> > -- Andrew Tanenbaum >> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> > >> > >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Wed, Jul 08, 2015 at 11:53:39AM +0200, Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: > > > >> On 8 Jul 2015, at 08:11, Garrett Wollman > >> wrote: > >> Perhaps the test was (erroneously) written to assume that > >> gettimeofday() was a system call, and could therefore detect invalid > >> pointers and return [EFAULT]. This has not been the case for some > >> time. (In HEAD, not since r237434, which is three years ago.) > > > > In defence of the test, the man page says it can return EFAULT. > > That's fine, but why changed the behaviour since 2015. May 27.? I have > an older FreeBSD/HardenedBSD install, where this test passing. See > some previous email in this thread. Current implemention detail is that gettimeofday(-1) causes SIGSEGV if kern.timecounter.hardware=TSC-low and kern.timecounter.fast_gettime=1. If you timecounter changed for whatever reason, the result of that call would fluctuate between EFAULT and signal. This is not the only test in the test set which checks something that cannot be reasonably explained. > > > > > (IMO the man page and test should change..) > > > > -- > > Daniel O'Connor > > "The nice thing about standards is that there > > are so many of them to choose from." > > -- Andrew Tanenbaum > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Jul 8, 2015, at 2:53, Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: >> >>> On 8 Jul 2015, at 08:11, Garrett Wollman >>> wrote: >>> Perhaps the test was (erroneously) written to assume that >>> gettimeofday() was a system call, and could therefore detect invalid >>> pointers and return [EFAULT]. This has not been the case for some >>> time. (In HEAD, not since r237434, which is three years ago.) >> >> In defence of the test, the man page says it can return EFAULT. > > That's fine, but why changed the behaviour since 2015. May 27.? I have > an older FreeBSD/HardenedBSD install, where this test passing. See > some previous email in this thread. Hmm… works for me at least (no non-upstreamed changes to the kernel/userland as far as I remember — just more tests and some related build stuff). Cheers, -NGie $ uname -a FreeBSD fuji-current-amd64.local 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r284769+70563d6(isilon-atf)-dirty: Thu Jul 2 13:19:45 PDT 2015 ngie@fuji-current-amd64.local:/usr/obj/usr/src/sys/FUJI amd64 $ cc -Wall -g -O0 -o busted_gettimeofday busted_gettimeofday.c $ ./busted_gettimeofday busted_gettimeofday: gettimeofday: Bad address $ cc -Wall -g -o busted_gettimeofday busted_gettimeofday.c $ ./busted_gettimeofday busted_gettimeofday: gettimeofday: Bad address $ cc -Wall -o busted_gettimeofday busted_gettimeofday.c $ ./busted_gettimeofday busted_gettimeofday: gettimeofday: Bad address signature.asc Description: Message signed with OpenPGP using GPGMail
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On 7/8/15, O'Connor, Daniel wrote: > >> On 8 Jul 2015, at 08:11, Garrett Wollman >> wrote: >> Perhaps the test was (erroneously) written to assume that >> gettimeofday() was a system call, and could therefore detect invalid >> pointers and return [EFAULT]. This has not been the case for some >> time. (In HEAD, not since r237434, which is three years ago.) > > In defence of the test, the man page says it can return EFAULT. That's fine, but why changed the behaviour since 2015. May 27.? I have an older FreeBSD/HardenedBSD install, where this test passing. See some previous email in this thread. > > (IMO the man page and test should change..) > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
> On 8 Jul 2015, at 08:11, Garrett Wollman > wrote: > Perhaps the test was (erroneously) written to assume that > gettimeofday() was a system call, and could therefore detect invalid > pointers and return [EFAULT]. This has not been the case for some > time. (In HEAD, not since r237434, which is three years ago.) In defence of the test, the man page says it can return EFAULT. (IMO the man page and test should change..) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article
oliver.pin...@hardenedbsd.org writes:
>We discovered that one of the kyua test failing from gettimeofday tests.
>The error is reproducible on recent snapshot from 11-CURRENT:
>ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
>
>root@freebsd:~ # cat test-gtod.c
>#include
>#include
>
>int
>main(int argc, char **argv)
>{
>
>return (gettimeofday((void *)-1, NULL));
>}
Undefined behavior here, so the implementation is allowed to do
literally anything at all. Certainly there's nothing wrong with it
dumping core here, and the test is erroneous if it expects otherwise.
The first argument to gettimeofday() MUST be a valid pointer to struct
timeval, and the implementation does depend on this.
Perhaps the test was (erroneously) written to assume that
gettimeofday() was a system call, and could therefore detect invalid
pointers and return [EFAULT]. This has not been the case for some
time. (In HEAD, not since r237434, which is three years ago.)
-GAWollman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Tue, Jul 7, 2015 at 3:17 PM, Oliver Pinter wrote: ... >> I have no idea where this broke because the Jenkins runs have been >> unreliable over the past few weeks ;(... > > Do you have died executors too? jenkins.freebsd.org does: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/buildTimeTrend . The executors have been timing out when running the tests. I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200447 to track the issue, but no progress so far... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Wed, Jul 8, 2015 at 12:09 AM, Garrett Cooper wrote:
>
>> On Jul 7, 2015, at 15:00, Oliver Pinter
>> wrote:
>>
>> Hi all!
>>
>> We discovered that one of the kyua test failing from gettimeofday tests.
>> The error is reproducible on recent snapshot from 11-CURRENT:
>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
>>
>> root@freebsd:~ # cat test-gtod.c
>> #include
>> #include
>>
>> int
>> main(int argc, char **argv)
>> {
>>
>>return (gettimeofday((void *)-1, NULL));
>> }
>> root@freebsd:~ # make test-gtod
>> cc -O2 -pipetest-gtod.c -o test-gtod
>> root@freebsd:~ # uname -a
>> FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
>> 30 22:05:35 UTC 2015
>> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
>> root@freebsd:~ # ./test-gtod
>> Segmentation fault (core dumped)
>>
>> root@freebsd:~ # gdb ./test-gtod
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...(no debugging
>> symbols found)...
>> (gdb) r
>> Starting program: /root/test-gtod
>> (no debugging symbols found)...(no debugging symbols found)...
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x000800958fbd in bcopy () from /lib/libc.so.7
>> (gdb) bt
>> #0 0x000800958fbd in bcopy () from /lib/libc.so.7
>> #1 0x559c1291 in ?? ()
>> #2 0xf9fde38df0174b80 in ?? ()
>> #3 0x in ?? ()
>> #4 0x in ?? ()
>>
>> And this is the original kyua test:
>> op@opn sys> kyua test gettimeofday_test
>> gettimeofday_test:gettimeofday_err -> broken: Premature exit; test
>> case received signal 11 (core dumped) [0.987s]
>> gettimeofday_test:gettimeofday_mono -> passed [0.014s]
>>
>> Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
>> Results saved to
>> /usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db
>>
>> 1/2 passed (1 failed)
>> op@opn sys> pwd
>> /usr/tests/lib/libc/sys
>
> Please file a bug.
Will do.
Btw, here is one of the know good state:
op@robot sys# kyua test gettimeofday_test
gettimeofday_test:gettimeofday_err -> passed [0.026s]
gettimeofday_test:gettimeofday_mono -> passed [0.004s]
Results file id is usr_tests_lib_libc_sys.20150707-221532-875455
Results saved to
/root/.kyua/store/results.usr_tests_lib_libc_sys.20150707-221532-875455.db
2/2 passed (0 failed)
op@robot sys# uname -a
FreeBSD robot.hardenedbsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #100
6ab779a(HEAD): Wed May 27 02:04:09 EDT 2015
jenk...@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-master-amd64/sys/HARDENEDBSD
amd64
op@robot sys#
>
> I have no idea where this broke because the Jenkins runs have been unreliable
> over the past few weeks ;(...
Do you have died executors too?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
> On Jul 7, 2015, at 15:00, Oliver Pinter wrote:
>
> Hi all!
>
> We discovered that one of the kyua test failing from gettimeofday tests.
> The error is reproducible on recent snapshot from 11-CURRENT:
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
>
> root@freebsd:~ # cat test-gtod.c
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>
>return (gettimeofday((void *)-1, NULL));
> }
> root@freebsd:~ # make test-gtod
> cc -O2 -pipetest-gtod.c -o test-gtod
> root@freebsd:~ # uname -a
> FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
> 30 22:05:35 UTC 2015
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> root@freebsd:~ # ./test-gtod
> Segmentation fault (core dumped)
>
> root@freebsd:~ # gdb ./test-gtod
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...(no debugging
> symbols found)...
> (gdb) r
> Starting program: /root/test-gtod
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGSEGV, Segmentation fault.
> 0x000800958fbd in bcopy () from /lib/libc.so.7
> (gdb) bt
> #0 0x000800958fbd in bcopy () from /lib/libc.so.7
> #1 0x559c1291 in ?? ()
> #2 0xf9fde38df0174b80 in ?? ()
> #3 0x in ?? ()
> #4 0x in ?? ()
>
> And this is the original kyua test:
> op@opn sys> kyua test gettimeofday_test
> gettimeofday_test:gettimeofday_err -> broken: Premature exit; test
> case received signal 11 (core dumped) [0.987s]
> gettimeofday_test:gettimeofday_mono -> passed [0.014s]
>
> Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
> Results saved to
> /usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db
>
> 1/2 passed (1 failed)
> op@opn sys> pwd
> /usr/tests/lib/libc/sys
Please file a bug.
I have no idea where this broke because the Jenkins runs have been unreliable
over the past few weeks ;(...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
Hi all!
We discovered that one of the kyua test failing from gettimeofday tests.
The error is reproducible on recent snapshot from 11-CURRENT:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
root@freebsd:~ # cat test-gtod.c
#include
#include
int
main(int argc, char **argv)
{
return (gettimeofday((void *)-1, NULL));
}
root@freebsd:~ # make test-gtod
cc -O2 -pipetest-gtod.c -o test-gtod
root@freebsd:~ # uname -a
FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
30 22:05:35 UTC 2015
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
root@freebsd:~ # ./test-gtod
Segmentation fault (core dumped)
root@freebsd:~ # gdb ./test-gtod
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging
symbols found)...
(gdb) r
Starting program: /root/test-gtod
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x000800958fbd in bcopy () from /lib/libc.so.7
(gdb) bt
#0 0x000800958fbd in bcopy () from /lib/libc.so.7
#1 0x559c1291 in ?? ()
#2 0xf9fde38df0174b80 in ?? ()
#3 0x in ?? ()
#4 0x in ?? ()
And this is the original kyua test:
op@opn sys> kyua test gettimeofday_test
gettimeofday_test:gettimeofday_err -> broken: Premature exit; test
case received signal 11 (core dumped) [0.987s]
gettimeofday_test:gettimeofday_mono -> passed [0.014s]
Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
Results saved to
/usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db
1/2 passed (1 failed)
op@opn sys> pwd
/usr/tests/lib/libc/sys
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
