Fix crashes caused by improper error handling on bpf_look/update/delete_elem

[maokelong]

bpf_*_elem returns -errno when error occured. These functions will return -ENOENT(-2) when they failed to find a entry. It's a harmless error that could be found when doing delete and print/zero/clear operations on the same map simultaneously. It's not reasonable to stop the whole program at this moment.

A simple script could reproduce this annoying situation:

i:us:1 {
    @data[rand % 100] = count();
    if (rand % 5 == 0) {
        delete(@data[rand % 10]);
    }
}

i:ms:1 {
    clear(@data);
    // or print(@data);
    // or zero(@data);
}

This script crashed almost immediately and reports errors likes:

Attaching 2 probes...
ERROR: failed to look up elem: -2
terminate called after throwing an instance of 'std::runtime_error'
  what():  Could not clear map with ident "@data", err=-1
fish: 'sudo bpftrace ../../../workspac…' terminated by signal SIGABRT (Abort)

But It's accepable for users that some entries are deleted asynchronously when tring to clear/print/zero a map.

Checklist

• Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
• User-visible and non-trivial changes updated in CHANGELOG.md
• The new behaviour is covered by tests

[danobi]

Change lgtm. But could you please add a runtime test so we can avoid future regressions?

The script you provided in your PR description seems reasonable to use.

Here's some hints on runtime tests: https://github.com/iovisor/bpftrace/blob/master/tests/README.md#runtime-tests

[maokelong]

Change lgtm. But could you please add a runtime test so we can avoid future regressions?

The script you provided in your PR description seems reasonable to use.

Here's some hints on runtime tests: https://github.com/iovisor/bpftrace/blob/master/tests/README.md#runtime-tests

@danobi Done. And here's the test report on my pc. : )

Without this patch:

With this patch:

[danobi]

Small nit but lgtm otherwise

[danobi]

thanks!

[viktormalik]

Looks good, thanks! Could you also add a CHANGELOG entry?

[danobi]

I'll push a changelog entry up for this

[ajor]

Thanks for the fix!

This did confuse me as I thought we'd already handled at least one of these cases years ago: #823

With a bit of digging it turns out that libbpf changed how they returned errors in 2021: libbpf/libbpf@7c7ba06