ci: Run analysis using CodeChecker

[Swatinem]

See https://github.com/Ericsson/codechecker

This basically is a frontend for clang-tidy and clang-static-analyzer.

[Swatinem]

Some examples of false positives I see with CTU running locally (had to disable that on CI for now):

[HIGH] /home/swatinem/Coding/sentry/sentry-native/src/sentry_string.c:39:5: Null pointer passed to 1st parameter expecting 'nonnull' [core.NonNullParamChecker]
    memcpy(sb->buf + sb->len, s, len);
    ^
  Report hash: bbf569e0c283fab9b521cb403de0903c
  Macro expansions:
    1, sentry_envelope.c:360:1: Macro 'MUST_USE' expanded to '__attribute__((warn_unused_result))'
  Steps:
     1, sentry_envelope.c:382:14: Calling 'sentry_envelope_write_to_path'
     2, sentry_envelope.c:360:1: Entered call from 'sentry_envelope_write_to_file'
     3, sentry_envelope.c:367:17: Calling 'sentry_envelope_serialize'
     4, sentry_envelope.c:348:1: Entered call from 'sentry_envelope_write_to_path'
     5, sentry_envelope.c:352:5: Calling 'sentry__stringbuilder_init'
     6, sentry_string.c:8:1: Entered call from 'sentry_envelope_serialize'
     7, sentry_string.c:11:5: Null pointer value stored to 'sb.buf'
     8, sentry_envelope.c:352:5: Returning from 'sentry__stringbuilder_init'
     9, sentry_envelope.c:354:5: Calling 'sentry__envelope_serialize_into_stringbuilder'
    10, sentry_envelope.c:291:1: Entered call from 'sentry_envelope_serialize'
    11, sentry_envelope.c:295:9: Assuming field 'is_raw' is true
    12, sentry_envelope.c:296:9: Calling 'sentry__stringbuilder_append_buf'
    13, sentry_string.c:53:1: Entered call from 'sentry__envelope_serialize_into_stringbuilder'
    14, sentry_string.c:57:12: Calling 'append'
    15, sentry_string.c:16:1: Entered call from 'sentry__stringbuilder_append_buf'
    16, sentry_string.c:20:9: Assuming 'needed' is <= field 'allocated'
    17, sentry_string.c:39:5: Null pointer passed to 1st parameter expecting 'nonnull'

I don’t think this can ever happen, as allocated will be 0 in that case; and needed is always >= 1 even if you want to append an empty string. Anyway, I will add another condition to it.

[MEDIUM] /home/swatinem/Coding/sentry/sentry-native/src/sentry_json.c:258:1: Potential leak of memory pointed to by 'formatted' [unix.Malloc]
}
^
  Report hash: d6367b9302465f90c90a3ab8eb9535cf
  Steps:
     1, sentry_json.c:255:23: Calling 'sentry__msec_time_to_iso8601'
     2, sentry_utils.c:327:1: Entered call from 'sentry__jsonwriter_write_msec_timestamp'
     3, sentry_utils.c:342:9: Assuming 'msecs' is 0
     4, sentry_utils.c:347:12: Calling 'sentry__string_clone'
     5, sentry_string.c:107:1: Entered call from 'sentry__msec_time_to_iso8601'
     6, sentry_string.c:110:18: Calling 'sentry__string_clonen'
     7, sentry_string.c:113:1: Entered call from 'sentry__string_clone'
     8, sentry_string.c:117:16: Calling 'sentry_malloc'
     9, sentry_alloc.c:13:1: Entered call from 'sentry__string_clonen'
    10, sentry_alloc.c:21:12: Memory is allocated
    11, sentry_string.c:117:16: Returned allocated memory
    12, sentry_string.c:118:9: Assuming 'rv' is non-null
    13, sentry_string.c:110:18: Returned allocated memory
    14, sentry_utils.c:347:12: Returned allocated memory
    15, sentry_json.c:255:23: Returned allocated memory
    16, sentry_json.c:258:1: Potential leak of memory pointed to by 'formatted'

Relevant code:

void
sentry__jsonwriter_write_msec_timestamp(sentry_jsonwriter_t *jw, uint64_t time)
{
    char *formatted = sentry__msec_time_to_iso8601(time);
    sentry__jsonwriter_write_str(jw, formatted);
    sentry_free(formatted);
}

lol, we just called sentry_free on it, how can that leak?

Looking at a lot more of these cases, I think the analyzer does not correctly handle ownership transfer of void*.
There are tons of false positives as well with sentry_path_free.

[Swatinem]

These cases here are interesting. Sure, new_thing_value allocates internally and can fail. But CTU can’t look through the sentry_value_is_null assertion and will still flag all of these as false positives.

[jan-auer]

Have you checked if there are annotations that you can place sentry_value_is_null to make it understand the invariants? I'd love to take a look at this CTU failure.

[Swatinem]

The problem why I do all the checks outside is that new_thing_value takes ownership of whatever its wrapping, but it doesn’t know how to free. Maybe with a separate function pointer argument, this becomes clearer.

[jan-auer]

Usually, there are attributes you can put on the function to declare this behavior. Since we encode the pointers in a strange way, it's understandable that tools don't follow the path.

Let's skip this for now.

[flub]

minor: personally this function is now too big and long for me to remember all variables in scope etc and i would break this up. at this point it's not problematic though, so i don't mind.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 53.12500% with 30 lines in your changes missing coverage. Please review.

Project coverage is 85.03%. Comparing base (30204bd) to head (ed26fdd).
Report is 409 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #304      +/-   ##
==========================================
- Coverage   85.20%   85.03%   -0.17%     
==========================================
  Files          49       49              
  Lines        3946     3975      +29     
==========================================
+ Hits         3362     3380      +18     
- Misses        584      595      +11     

[jan-auer]

Have you checked if there are annotations that you can place sentry_value_is_null to make it understand the invariants? I'd love to take a look at this CTU failure.