Re: [Qemu-devel] broken HMP command: info mtree

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Feb 12, 2016 at 02:27:23PM +0100, Igor Mammedov wrote:
> On Fri, 12 Feb 2016 14:08:32 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 12/02/2016 12:17, Daniel P. Berrange wrote:
> > > On Fri, Feb 12, 2016 at 12:15:26PM +0100, Igor Mammedov wrote:  
> > >> On Thu, 11 Feb 2016 16:35:39 +0100
> > >> Igor Mammedov <imammedo@redhat.com> wrote:
> > >>  
> > >>> executing 'info mtree' from monitor prompt causes infinite loop
> > >>> printing it over and over.
> > >>>
> > >>> to reproduce build current master adn run:
> > >>>
> > >>> qemu-system-x86_64 -monitor stdio
> > >>>
> > >>> and then execute 'info mtree' in monitor prompt  
> > >>
> > >> it bisects to:
> > >>
> > >> commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2
> > >> Author: Daniel P. Berrange <berrange@redhat.com>
> > >> Date:   Tue Jan 19 11:14:29 2016 +0000
> > >>
> > >>     char: convert from GIOChannel to QIOChannel
> > >>     
> > >>     In preparation for introducing TLS support to the TCP chardev
> > >>     backend, convert existing chardev code from using GIOChannel
> > >>     to QIOChannel. This simplifies the chardev code by removing
> > >>     most of the OS platform conditional code for dealing with
> > >>     file descriptor passing.
> > >>     
> > >>     Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > >>     Message-Id: <1453202071-10289-3-git-send-email-berrange@redhat.com>
> > >>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > >>
> > >>
> > >> build with:
> > >> ./configure --target-list=x86_64-softmmu --enable-debug 
> > >> on RHEL72ish host
> > >>
> > >> monitor output has to be stdio  
> > > 
> > > Sigh, so much pain from the chardev code. I'll investigate and send a
> > > suitable patch asap.  
> > 
> > Hmm, I cannot reproduce this though.
> Perhaps I'm affected because my stdout goes via remote ssh session.
> 
> It looks like monitor tries to flush buffer but succeeds only partially
> and returns with EAGAIN and on the next flush attempt it tries to
> flush the same buffer again from the first byte again

Yes, it turned out to need a moderately slow console like a distant
ssh connection to trigger the EGAIN situation. I've just sent a patch.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|