Date: Sun, 15 Jan 2017 11:08:13 +0200
From: Andreas Gustafsson <g...@gson.org>
Message-ID: <22651.15357.143730.605...@guava.gson.org>
| the following test cases are all timing out:
|
| lib/libc/gen/t_sleep:kevent
| lib/libevent/t_event:kqueue
| lib/libevent/t_event:poll
| lib/libevent/t_event:select
As I recall those have been timing out for ages (I assumed probably
related to the qemu timimg issue, as they're all timer sensitive.)
So that leaves just ...
| lib/libc/ssp/t_ssp:fgets
| lib/libc/ssp/t_ssp:getcwd
| lib/libc/ssp/t_ssp:gets
| lib/libc/ssp/t_ssp:memcpy
| lib/libc/ssp/t_ssp:memmove
| lib/libc/ssp/t_ssp:memset
| lib/libc/ssp/t_ssp:raw
| lib/libc/ssp/t_ssp:read
| lib/libc/ssp/t_ssp:readlink
| lib/libc/ssp/t_ssp:snprintf
| lib/libc/ssp/t_ssp:sprintf
| lib/libc/ssp/t_ssp:stpcpy
| lib/libc/ssp/t_ssp:stpncpy
| lib/libc/ssp/t_ssp:strcat
| lib/libc/ssp/t_ssp:strcpy
| lib/libc/ssp/t_ssp:strncat
| lib/libc/ssp/t_ssp:strncpy
| lib/libc/ssp/t_ssp:vsnprintf
| lib/libc/ssp/t_ssp:vsprintf
as new failures. I cannot see any reason changes to syslog could be
in any way related (none of the ssp tests use syslog), however at about
the same time ...
commit 2017.01.12.00.43.55 christos src/lib/libc/include/extern.h 1.25
commit 2017.01.12.00.43.55 christos src/lib/libc/string/strerror_ss.c 1.2
and these - according to the i386 build log where they did start timing
out before the build broke, yet again, these were the last changes before
the timeouts started ... the build after the syslog changes has, just
recently, completes its test run - now b5 appears to be checking to see
if
commit 2017.01.12.00.38.25 riastradh src/lib/libc/README 1.6
might have caused the issue! We really should make things a little smarter
and know that changes to readmes or CHANGES files, etc, cannot have any
effect on anything, and not do a build when that is the only change, and
not bother doing, as now, and bisecting the changes treating this as if it
might have caused a problem.
While I cannot see why adding the strerror_ss() function to libc
(which is what Christos' two changes accomplish) could break anything, it
is more plausible than syslog changes (which were ruled out while I was
composing this message anyway.)
kre
