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