On 04/18/2013 04:30 AM, Martin Kletzander wrote:
On two places, there were errors not being reported. One strdup
without virReportOOMError() and call for virFileMakePathHelper() which
doesn't report any errors, just sets errno (or leaves it set by
underlying functions).
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
---
src/util/virutil.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Needs work. Right now, this function intentionally does not report
errors; all direct callers (src/util/virlockspace.c and tools/virsh.c)
are aware of this convention.
On the other hand, I looked through indirect callers of
virFileMakePath(), and found at least the following problems:
daemon/libvirtd.c: daemonPidFilePath() doesn't report an error
src/conf/*_conf.c: 5 callers report error
libxl_driver.c: reports errors with VIR_ERROR instead of
virReportSystemError, so it gets logged but not reported to caller
src/locking/lock_daemon.c: same bug as daemon/libvirt.c
I stopped looking here - lots of other callers, and probably a similar
mix of functions that report the error themselves, vs. functions that
fail to do error reporting.
We need to decide which way to go, then audit ALL users to obey that
convention. Note that there are cases (such as tools/virsh.c) that
intentionally want to suppress errors of EEXIST, except that
virFileMakePathHelper already guarantees that EEXIST won't be the cause
of failure, so maybe cleaning up ALL callers to expect virutil.c to do
error reporting is the way to go.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org