Date: Sun, 15 Jan 2017 13:41:01 +0200
From: Andreas Gustafsson <g...@gson.org>
Message-ID: <22651.24525.719962.508...@guava.gson.org>
| security(7) says "Upon detection of a buffer overrun, SSP will
| immediately abort execution of the program and send a log message
| to syslog(3)."
OK, I am currently doing a full build so I can test this (I've been away,
and my test system was rather stale...) That gives a better clue where to
look (if Christos doesn't fix it before I get the opportunity to debug).
| The tests of 2017.01.12.00.38.01 sources yielded "new failures: 19
| test cases" rather than "did not complete" because I increased the
| timeout before that test was run.
Yes, figured that out just after sending the first message...
| CPU time is cheap, and I think there is value in being able to say
| that you have actually tested the sources immediately before and after
| a suspect commit, rather than relying on the assumption that certain
| types of commits can't possibly cause problems.
I guess ... when I first was thinking of this issue I was considering
more what should trigger a normal build cycle to start - clearly there's
no point if there have been no commits since the last build... I was thinking
that perhaps we could save some resources (more tests seem to fail when b5
is busy doing lots of parallel compiles and tests it seems) by not starting
a build if the only changes are ones that are very unlikely to cause
problems (almost any doc commit would count). After a commit to a .c .h .sh
or build system file (Makefiles, anything.mk, set lists, ...) then start
the next build cycle (which will also test any earlier doc, etc, changes of
course, just in case a *roff error or something causes a failure). If all
works, great, if it fails, then it could do the same as now and attempt to
find the cause by dividing the commits.
kre
