Hi Thomas, > 1. I didn't have --enable-cassert enabled before. Oops. > 2. It'll now dump a gdb backtrace for any core files found after a > check-world failure (if you can find your way to the build log...). > Thanks to Andres for the GDB scripting for this! > 3. It'll now push gcov results to codecov.io -- see link at top of > page. Thanks again to Andres for this idea. > 4. It now builds a little bit faster due to -j4 (Travis CI VMs have 2 > virtual cores) and .proverc -j3. (So far one entry now fails in TAP > tests with that setting, will wait longer before drawing any > conclusions about that.)
Wow. Well done! > LLVM sanitizer stuff In my experience it doesn't work well with PostgreSQL code, way to many false positives. For more details see this discussion [1]. > Valgrind That would be great. Please note that Valgrind generates false reports regarding memory leaks in PostgreSQL so you should use --leak-check=no. Also USE_VALGRIND should be defined in src/include/pg_config_manual.h before building PostgreSQL. Here [2] is a script I'm using. > Coverity I believe it would be not easy to integrate with the web-version of Coverity. On the other hand Clang Static Analyzer often finds real defects and it's very easy to integrate with it. Here is my script [3]. > more compilers, <your idea here> In my experience trying to compile a patch on FreeBSD with Clang often helps to find some sort of defect. Same regarding trying different architectures, e.g. x64, x86, arm. [1]: https://www.postgresql.org/message-id/20160321130850.6ed6f598%40fujitsu [2]: https://github.com/afiskon/pgscripts/blob/master/valgrind.sh [3]: https://github.com/afiskon/pgscripts/blob/master/static-analysis.sh -- Best regards, Aleksander Alekseev
signature.asc
Description: PGP signature