On Tue, Nov 02, 2010 at 02:02:24PM -0600, Eric Blake wrote: > 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. okidoc, applied and pushed, thanks ! Daniel -- 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