This is a bug I found while testing the smbios support, it uses
virPipeReadUntilEOF to read the stdout of the exec'ed dmidecode
process and this failed to capture the full output. It read only
1024 bytes.
The problem is that this is based on a poll loop, and in the
loop we read at most 1024 bytes per filedescriptor, but we also
note in the loop if poll indicates that the process won't output
more than that on that fd by setting finished[i] = 1.
The simplest way is that if we read a full buffer make sure
finished[i] is still 0 because we will need another pass in the
loop.
Daniel
diff --git a/src/util/util.c b/src/util/util.c
index f7c7d32..a059675 100644
--- a/src/util/util.c
+++ b/src/util/util.c
@@ -984,6 +984,9 @@ virPipeReadUntilEOF(int outfd, int errfd,
got = read(fds[i].fd, data, sizeof(data));
+ if (got == sizeof(data))
+ finished[i] = 0;
+
if (got == 0) {
finished[i] = 1;
continue;
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list