workflows: Drop i386 clang check-memory

[martinpitt]

In recent Debian testing, valgrind now shows a gazillion
Memcheck:{Cond,Value4} errors all over the place: in GMP, GnuTLS, glib
hashtables, and even strcmp(). Give up at last, and run valgrind on 64
bit only. This also becomes less important with us moving more and more
code away from C.

Add a comment about the explicit "check" run. It was introduced in
commit 1ef0001 to run static code checks, which don't work against a
tarball in "distcheck".

Change the order in unit-tests-refresh.yml to match the order in
unit-tests.yml to reduce confusion.

---

This should fix the unit-tests-refresh run which has been failing for over two weeks. @jelly spent an hour on this, I spent over two, and now I just give up and refuse. If anyone else is interested in working on this, please do.

[martinpitt]

This is my current tools/gnutls.supp , which helps a lot:

# TODO: forward upstream
{
   nettle_gmp_uninitialized
   Memcheck:Cond
   fun:__gmpn_*
   fun:_nettle_*
   fun:gnutls_handshake
}
{
   nettle_gmp_uninitialized
   Memcheck:Value4
   fun:__gmpn_*
   fun:_nettle_*
   fun:gnutls_handshake
}

# sometimes the trace is truncated
{
   nettle_gmp_uninitialized
   Memcheck:Cond
   fun:__gmpn_*
}
{
   nettle_gmp_uninitialized
   Memcheck:Value4
   fun:__gmpn_*
}

# TODO: forward upstream
{
   verify_crt2_uninitialized
   Memcheck:Cond
   ...
   fun:gnutls_x509_trust_list_verify_crt2
}
{
   verify_crt2_uninitialized
   Memcheck:Value4
   ...
   fun:gnutls_x509_trust_list_verify_crt2
}

{
   verify_digest_uninitialized
   Memcheck:Value4
   ...
   fun:nettle_rsa_pss_sha256_verify_digest
}
{
   verify_digest_uninitialized
   Memcheck:Cond
   ...
   fun:nettle_rsa_pss_sha256_verify_digest
}

But after that, there's tons of stupid stuff like

{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:g_pattern_ph_match
   fun:g_pattern_ph_match
   fun:g_pattern_ph_match
   fun:g_pattern_spec_match
   fun:g_pattern_match_simple
   fun:_cockpit_assert_strmatch_msg
   fun:test_webserver_tls_big_header
   fun:test_case_run
   fun:g_test_run_suite_internal
   fun:g_test_run_suite_internal
   fun:g_test_run_suite
   fun:g_test_run
   fun:main
}

or

{    
   <insert_a_suppression_name_here>    
   Memcheck:Cond    
   fun:strcmp       
   fun:g_str_has_suffix    
   fun:cockpit_web_response_content_type        
   fun:finish_headers    
   fun:cockpit_web_response_headers_full    
   fun:cockpit_web_response_headers_full    
   fun:cockpit_web_response_content        
   fun:on_shell_index_html    
   obj:/usr/lib/i386-linux-gnu/libffi.so.8.1.2    
   obj:/usr/lib/i386-linux-gnu/libffi.so.8.1.2    
   fun:g_cclosure_marshal_generic           
   fun:g_closure_invoke    
   fun:signal_emit_unlocked_R.isra.0    
   fun:signal_emit_valist_unlocked       
   fun:g_signal_emit_valist    
   fun:g_signal_emit       
   fun:cockpit_web_server_default_handle_stream    
   fun:cockpit_web_request_process    
   fun:cockpit_web_request_parse_and_process    
   fun:cockpit_web_request_on_input    
   fun:tls_source_dispatch    
}                                                  

I checked a few of these, and the code is clearly correct.

[martinpitt]

I already dropped the two required statuses, as for a few days we'll have a mix of "old" and "new" PRs. Then we can put the new ones back.

[martinpitt]

Meh, thought so -- running distcheck on amd64 is quite expensive 😢

[allisonkarlitskaya]

Meh, thought so -- running distcheck on amd64 is quite expensive 😢

Why is that more expensive than i386?

I think the latest version has too many scenarios. I was imagining going down from 4 to 3, not up to 5...

[martinpitt]

Why is that more expensive than i386?

This was for my previous version which ran both "check" and "distcheck" in the same scenario. AFAIUI we need "check" separately to run the static code tests (which are not run in distcheck due to not having a .git directory).

I think the latest version has too many scenarios. I was imagining going down from 4 to 3, not up to 5...

Do you have an idea how to mix them then? Or you want to give up on valgrind/clang? (That's still be 4, though)

[martinpitt]

@allisonkarlitskaya Reworked as discussed.

[allisonkarlitskaya]

Looks good, thanks.

[jelly]

Oh, this was i386 only! I checked and thought it would be clang 14 issue and as Debian wasn't updated yet to something newer we couldn't remove it. But seems I'm wrong \o/

[martinpitt]

I started a production refresh