2017-09-28 05:25:03 -04:00
|
|
|
# Configuration file for LeakSanitizer run on the Travis CI
|
|
|
|
|
|
|
|
# TBB leaks some memory allocated in singleton depending on deinitialization order
|
|
|
|
# Direct leak of 1560 byte(s) in 3 object(s) allocated from:
|
|
|
|
# #0 0x7f7ae72a80a0 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc80a0)
|
|
|
|
# #1 0x7f7ae595d13e (/usr/lib/x86_64-linux-gnu/libtbb.so.2+0x2213e)
|
|
|
|
|
|
|
|
leak:libtbb.so
|
2023-03-23 14:18:58 -04:00
|
|
|
|
|
|
|
# The extract-tests leak some memory in the tests to confirm that
|
|
|
|
# lua errors print tracebacks.
|
|
|
|
# This appears to be because when these tests throw exceptions, the
|
|
|
|
# osmium objects being processed are not freed. In production this doesn't
|
|
|
|
# matter, as the exceptions bring down the entire osrm-extract process. In the
|
|
|
|
# tests, we catch the error to make sure it occurs, which is why the
|
|
|
|
# leaksanitizer flags it.
|
|
|
|
leak:extract-tests
|