openssl: CI sanitizer runs: limit amount of memory leak output

When a memory leak is detected by libasan, its output usually contains a horribly long list of indirect memory leaks with lots of redundant or irrelevant data, which is rarely helpful but very awkward to handle - both in a terminal and in a browser window much inefficient scrolling is needed. Typically it is sufficient to have a look at the (first) direct leak, which gets printed first, in order to find out which data got leaked.

A related FR was filed for AddressSanitizer/LeakSanitizer in https://github.com/google/sanitizers/issues/1250 They did not provide an option to suppress output of indirect leaks, but mentioned the possibility to use, e.g.,

LSAN_OPTIONS="max_leaks=1"

I propose adding something like this (by default) to sanitizer CI runs.

About this issue

Original URL
State: closed
Created 9 months ago
Comments: 30 (30 by maintainers)

Most upvoted comments

PR updated

nhorman on Nov 13, 2023

2. This is occuring because the test is considering the exit code of the filter_asan script rather than the exit code of the make job.

Regarding this issue and the potential extra overhead due to that script, it would be less brittle and more efficient to do the (conditional) filtering within the existing Perl-based output processing, i.e., in test/run_tests.pl or the underlying TAP::Parser

DDvO on Nov 11, 2023

It slows ci down significantly (9m typically vs 15 minutes in the draft pr. that seems like a huge increase, but I’ve run it multiple times, and it seems consistent.

You should not compare with the execution time of runs not having mem leaks (because dependent on the amount of mem leaks, the internal ASAN reporting machinery may cause significant slowdown even without later external filtering) but runs having the same mem leaks, where the only difference is using the external filter or not.

DDvO on Nov 11, 2023

Yeah, the tools repo sounds like a good home

nhorman on Oct 31, 2023

closing given that the corresponding PR is closed

nhorman on Oct 23, 2023

Whats the advantage to doing so? I don’t mean to sound flippant over the request, and I understand that the ci output can be verbose, but it seems relatively easy to filter out the redundant traces with a script after the ci run, compared to having to modify the CI job in the event that someone wants the verbose output (saying this with the understanding the max_leaks=1 is kind of a large hammer that suppresses subsequent unique leaks after the first).

perhaps what we need is to modify the ci job to log leaks to a separate file in ci that can then be downloaded and massaged with such a script?

nhorman on Oct 7, 2023