is_method_error versus call() errors

Patrick Venture venture at google.com
Tue Sep 11 02:17:45 AEST 2018


Given:

_public_ int sd_bus_message_is_method_error(sd_bus_message *m, const
char *name) {
        assert_return(m, -EINVAL);
        if (m->header->type != SD_BUS_MESSAGE_METHOD_ERROR)
                return 0;
        if (name && (!m->error.name || !streq(m->error.name, name)))
                return 0;
        return 1;
}

The failures from call() don't always set the reply (maybe don't ever,
but I didn't read it closely).  Which means, is_method_error() can
happen when the bus call itself was fine, so we need to check both IFF
we're going to read the response.

I'm working on eliminating the new crashes from phosphor-host-ipmid
and other repositories, now that sdbusplus can except, which is not
caught even though there's an error case for is_method_error()
immediately after the call.

In phosphor-pid-control, I dropped the is_method_error() check, but I
think it's still valid before trying to read() a message -- so I will
likely throw a patch adding that check.

Patrick


More information about the openbmc mailing list