Some static inline functions are red

[evverx]

It can be reproduced by building dbus-broker with run_both.sh dbus-broker 10.

Below is the relevant part of fuzz-message.covreport:

LLVMFuzzerTestOneInput:
   22|     20|int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
   23|     20|        _c_cleanup_(message_unrefp) Message *message = NULL;
  ------------------
  |  |   91|     20|#define _c_cleanup_(_x) __attribute__((__cleanup__(_x)))
  ------------------
...

fuzz-message.c:message_unrefp:
  802|     20|        static inline void _func ## p(_type *p) {                               \
  803|     20|                if (*p)                                                         \
  ------------------
  |  Branch (803:21): [True: 18, False: 2]
  ------------------
  804|     20|                        _func(*p);                                              \
  805|     20|        } struct c_internal_trailing_semicolon
...

fuzz-message.c:message_unref:
  134|     18|static inline Message *message_unref(Message *message) {
  135|     18|        if (message)
  ------------------
  |  Branch (135:13): [True: 18, False: 0]
  ------------------
  136|     18|                ref_dec(&message->n_refs, message_free, NULL);
  137|     18|        return NULL;
  138|     18|}

[DavidKorczynski]

Interesting -- I had no idea about __attribute__((__cleanup__(_x))) until this.

There seems to be an inconsistency in the calltree and the coverage report regarding conclusion as to where the functions are declared.

From the calltree:

  message_unrefp /src/dbus-broker/src/dbus/message.h linenumber=46
    message_unref /src/dbus-broker/src/dbus/message.h linenumber=154

and the coverage report:

fuzz-message.c:message_unrefp:
  802|     25|        static inline void _func ## p(_type *p) {                               \
  803|     25|                if (*p)                                                         \
...
...
fuzz-message.c:message_unref:
  134|     23|static inline Message *message_unref(Message *message) {
  135|     23|        if (message)

i.e. the coverage report has the implementations in fuzz-message.c and calltree in message.h

Will have to dig more into this.

[evverx]

My guess would be that it affects static inline functions that can be instantiated in different places. I'll try to double-check and change the issue title if that is the case.

[DavidKorczynski]

static inline functions

Yeah, I suspect this too.

[evverx]

I'm not sure why message_unrefp isn't red though.

grep 'message_unrefp:' ./oss-fuzz/corpus-0/inspector-report/fuzz-message.covreport
message.c:message_unrefp:
fuzz-message.c:message_unrefp:

grep message_unrefp ./oss-fuzz/corpus-0/inspector-report/fuzzerLogFile-0-0b1YLQMAlg.data
      message_unrefp /src/dbus-broker/build/../src/dbus/message.h linenumber=36
    message_unrefp /src/dbus-broker/build/../src/dbus/message.h linenumber=91
  message_unrefp /src/dbus-broker/src/dbus/message.h linenumber=46

[evverx]

FWIW the pattern with the "cleanup" attribute is used extensively by systemd as well so its call trees are similar:

There those destructors aren't among fuzz blockers though so it's easier to ignore them.