On 11/02/2010 01:39 PM, Daniel Veillard wrote:
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;
+
ACK. Worst case is a file that is exactly a multiple of 1024 now
requiring one extra read to ascertain this fact, but that's not bad.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org