Overview

This issue aims to enhance the failure proofing of CAF by leveraging fil-c, a C/C++ runtime memory and safety checker. The goal is to identify common unsafe memory patterns in CAF tests and integrate fil-c error checks into our CI pipeline.

Error Case Example

A specific error caught by fil-c during libcaf_net/caf-net-test is shown below:

filc safety error: cannot read pointer with null object.
    pointer: 0x7f049caa0c50,<null>
    expected 8 bytes with ptr aligned to 8 bytes.
semantic origin:
    <somewhere>: caf::net::(anonymous namespace)::default_multiplexer::do_start(caf::intrusive_ptr<caf::net::socket_manager> const&)
check scheduled at:
    <somewhere>: caf::net::(anonymous namespace)::default_multiplexer::do_start(caf::intrusive_ptr<caf::net::socket_manager> const&)
    ...
[11234] filc panic: thwarted a futile attempt to violate memory safety.
Trace/breakpoint trap (core dumped)

As the first step, we should examine the error to check the root cause. It might as well be a false positive since our ASAN CI didn't catch it.

This should be a good warmup to check how the compiler and runtime library operate, and to decide if we want to integrate it into our CI as a pipeline job that runs a fil-c build of our test suite.