Add -fsanitizer=address for debug builds in travis

[TheMarex]

• Fix osrm-extract triggers the address sanitizer #2788
• Figure out why https://travis-ci.org/Project-OSRM/osrm-backend/jobs/153525916 is using the sanitizer
• Review
• Address comments.

[daniel-j-h]

Instead of hardcoding options for asan / msan / tsan / ubsan / ... it's probably cleaner to just set the env var

CXXFLAGS=-fsanitize=X

and let CMake pick it up automatically.

[TheMarex]

This fails because osrm-extract is triggers the sanitizer https://travis-ci.org/Project-OSRM/osrm-backend/jobs/153525915#L1824-L1882 which is tracked #2788

[TheMarex]

We are currently hitting http://stackoverflow.com/questions/37603238/fsanitize-not-using-gold-linker-in-gcc-6-1 with GCC. Switching to clang now and see if that works.

[oxidase]

@TheMarex the problem was in linking example without gold against OSRM libraries built with gold. It is only ubuntu gcc 6.1 issue. gcc 6.2 works fine. I have committed to my repository https://github.com/oxidase/osrm-backend/tree/build/add-sanitize to avoid forced push to upstream.

There were 2 problems:

• lazy TBB init without cleanup -> added explicit init
• shared memory leaks to prevent -> it is just bad implementation and must be fixed in Move shared memory block swapping control to osrm-datastore #2570

If it looks ok, i can squash commits and push into upstream.

[TheMarex]

@oxidase thanks for looking into this! 👍 I added some comments on your branch. You can pull in the changes here if you think my comments are resolved.

[oxidase]

The issue /usr/bin/ld: unrecognized option '--push-state' is due to missing '-fuse-ld=gold' in the example that is built with gcc-6.2 from the toolchain PPA and ld 2.24 from trusty that are not fully compatible. There is a problem with binutils 2.24 that do not support the option introduced by asan.

I have added a binutils PPA that bumps version to 2.27 for the debug asan build. It can be removed when binutils in the toolchain PPA will be updated to at least 2.26 or travis will switch to xenial.

[TheMarex]

@oxidase thanks for looking into this again. Great to see this working finally. 💯

I'm going to do the following things here:

• Split the commit up into different commit for build system/travis changes
• Split the code changes from the commit into an own commit

If we wait for #3015 the shared memory fixes are obsolete anyway since the whole ownership mode got reworked.