| Summary: | bogofilter-1.0.2 fails test t.bulkmode when compiled with hardened (ssp) and -Os | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Benno Schulenberg <bensberg> |
| Component: | New packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | hardened |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | everything in the output dir of the failing test, except the 320K wordlist.db | ||
|
Description
Benno Schulenberg
2006-08-10 03:16:12 UTC
Can someone from hardened have a look and/or give advice? All passes fine here. Benno, can you attach the file ./checks.29608.20060810T120300/bogolex-batch.out from the working directory? (e.g. in /var/tmp/portage/bogofilter-1.0.2/work/bogofilter-1.0.2/src/tests) Created attachment 95727 [details]
everything in the output dir of the failing test, except the 320K wordlist.db
After running 'SUPPRESS_DELETE=yes make check' in /var/tmp/portage/bogofilter-1.0.2/work/bogofilter-1.0.2/src/tests/
this is the content of bogolex-batch.out from checks.10746.20060902T141543:
u 0.499414
u 0.500000
u 0.500000
u 0.500392
u 0.522257
u 0.501194
S 7.80e-05
S 9.57e-10
Ah; after quite some effort, I managed to reproduce the fault, and found the trigger. It's the '-Os' that triggers it - with '-O2' everything works fine. I suspect the real issue is that the tests that fail are expecting too much arithmetic accuracy from floating point operations, rather than -Os itself being incorrect. I've seen this sort of thing before (in glibc's tests, no less), where tests are written against a "golden executable", using the output of that as the data to be checked when the tests are run against a new build. One problem (there are several others ;) ) with this approach is that it does not take account of unexpected accuracy; for example if the compiler can calculate stuff itself, it will - and it will do so at full precision (whatever is most convenient for the compiler, provided the precision is as good or better than required), not at single-precision float for example. Variations in optimisation cause changes in how and where the compiler can pre-calculate constants like this; previously I've seen it triggered by PIE; but clearly this case shows it can happen with SSP in combination with -Os, as it is here. When such changes in compiler behaviour mean it actually generates code to do the calculation at run-time, the precision will be that of the types specified; i.e. single-precision float, with no "free" extra precision. My recommendation would be to avoid -Os and use -O2 on hardened systems; it's what we set in the hardened profile, mainly because it's the optimisation level that is most commonly used. -Os is a bit specialised - it focuses on code size and sacrifices code speed (e.g. it skips the various alignment optimisations, causing a speed impact on the memory subsystem). Unless you really do have an issue with the size of executables, stick with -O2. Above -O2, the optimisations all start to be specialised, in that they are a benefit in some situations, but a drawback in others (that's why they're not in '-O2'). See 'info gcc' section 3.10 for details. (-fomit-frame-pointer is fine, btw - it helps with PIE building, but sacrifices some debug-ability which is not something that is a common concern on production hardened systems) Tove: as far as bogofilter is concerned, if you want to do anything at all then you could issue an 'ewarn' in the src_test phase conditional on 'gcc-specs-ssp' (from toolchain-funcs.eclass) and having -Os in CFLAGS, but I don't think it's worth it. If anyone else trips it, they should find this bug (I've beefed up the summary to help trigger searches). Thanks for the thorough explanation and advice, Kevin, it's much appreciated. Indeed, with -O2 the wayward test passes; I should have found this myself. Soon I'll recompile the whole system with -O2. Kevin, thank you very much for your investigation and explanation. I am not adding a warning to src_test for now. |
