Subject: Re: [PATCH] CI: add SANITIZE=[address|undefined] jobs

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Tue, 26 Jul 2022 15:33:50 +0200

On Tue, Jul 26 2022, Derrick Stolee wrote:

> On 7/26/2022 7:09 AM, Ævar Arnfjörð Bjarmason wrote:
>> Add CI targets for SANITIZE=address and SANITIZE=undefined. The former
>> would have caught a regression in 18bbc795fc5 (Merge branch
>> 'gc/bare-repo-discovery', 2022-07-22) which made its way to
>> "master"[1].
>> 
>> Per [2] the GitHub fork of git.git runs with these in CI, so it's
>> already useful to some forks of this repository.
>
> I'm a fan of adding additional sanitizer checks in our CI. Let's let
> computers do the work for us here instead of relying on humans.

Thanks, good to have agreement on adding these CI runs.

>> Also per [2] we could use SANITIZE=address with some ASAN_OPTIONS
>> instead of our SANITIZE=leak job added in 956d2e4639b (tests: add a
>> test mode for SANITIZE=leak, run it in CI, 2021-09-23), but unifying
>> those two with these new jobs would be a lot harder, so let's leave
>> that for now.
>>            - jobname: linux-leaks
>>              cc: gcc
>>              pool: ubuntu-latest
>> +          - jobname: SANITIZE=address
>> +            cc: gcc
>> +            pool: ubuntu-latest
>> +          - jobname: SANITIZE=undefined
>> +            cc: gcc
>> +            pool: ubuntu-latest
>
>> @@ -277,6 +277,12 @@ linux-leaks)
>>  	export SANITIZE=leak
>>  	export GIT_TEST_PASSING_SANITIZE_LEAK=true
>>  	;;
>> +SANITIZE=address)
>> +	export SANITIZE=address
>> +	;;
>> +SANITIZE=undefined)
>> +	export SANITIZE=undefined
>> +	;;
>
> In both of these cases, we are breaking from the nearby pattern. These
> jobs could be renamed to linux-address and linux-undefined to match the
> linux-leaks job.
>
> Alternatively, we could rename linux-leaks to SANITIZE=leak[...]

I deliberately deviated from the "linux-leaks" pattern since it's a lot
more than just:

	make SANITIZE=leak test

I.e. we instrument what tests we run, skip some individual ones
etc. These are different in that we can run the entire set. I'd think
the reverse would make sense, i.e. one day if we run fully with
SANITIZE=leak enabled to rename that job to "SANITIZE=leak".

> [...], since the
> point is not to test the Linux platform but to use the additional runtime
> checks (and Linux is the fasted CI platform).

Strictly speaking these tests are platform-specific in that they require
us to take certain codepaths at runtime, so if we have any
platform-specific code, or code that's affected by compilation options
(say NO_REGEX=Y v.s. using the libc's) we might see failures on one
platform, but not another. Compilation flags also matter (e.g. -O0
v.s. -O3).

But I think for all of [leak,address,undefined] it's a sensible
trade-off for now to just pick one specific platform.

Since it's very unlikely that the resulting issues are OS-specific I
thought it made sense to leave "linux" out of it, just like we have
"pedantic", not "linux-pedantic", ditto "sparse" which is also
platform-specific around the edges.

Having said all that I really don't care much what we call these as long
as we get the test coverage, but I'll hold off on any possible re-roll
to see if others chime in about the bikeshed :)