From: Eduardo Habkost <ehabkost@redhat.com>
To: "Lukáš Doktor" <ldoktor@redhat.com>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Cleber Rosa" <crosa@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2] qmp.py: Fix exception parsing partial JSON
Date: Fri, 8 Jun 2018 15:01:39 -0300 [thread overview]
Message-ID: <20180608180139.GM7451@localhost.localdomain> (raw)
In-Reply-To: <ff4501f9-f45e-dc96-9f02-861458fee39b@redhat.com>
On Fri, Jun 08, 2018 at 07:57:55PM +0200, Lukáš Doktor wrote:
> Hello guys,
>
> Dne 7.6.2018 v 01:06 Philippe Mathieu-Daudé napsal(a):
> > On 06/06/2018 05:05 PM, Eduardo Habkost wrote:
> >> On Wed, Jun 06, 2018 at 04:27:31PM -0300, Philippe Mathieu-Daudé wrote:
> >>> The readline() call returns partial data.
> >>
> >> How can this be reproduced? Despite not being forbidden by the
> >> QMP specification, QEMU normally doesn't break QMP replies in
> >> multiple lines, and readline() is not supposed to return a
> >> partial line unless it encounters EOF.
> >
> > $ git rev-parse HEAD
> > c1c2a435905ae76b159c573b0c0d6f095b45ebc6
> >
> > config copy/pasted from:
> > https://wiki.qemu.org/index.php/Documentation/QMP#Trying_it
> > (now looking at it, it seems I'm mixing configs...)
> >
> > $ cat qmp.conf
> > [chardev "qmp"]
> > backend = "socket"
> > path = "/tmp/qmp.sock"
> > server = "on"
> > wait = "off"
> > [mon "qmp"]
> > mode = "control"
> > chardev = "qmp"
> > pretty = "on"
> >
>
> nice, pretty printing..., didn't expected that.
Oh, so *that*'s the root cause. Thanks, I stared at this
configuration for a while and I couldn't see what could cause
extra newlines to appear in the output. :)
[...]
> >>> I'm sure there is a nicer/more pythonic way to do this, but this works for me,
> >>> sorry :)
> >>
> >> It looks like there's no elegant solution for this:
> >> https://stackoverflow.com/a/21709058
> >>
>
> Yep, that looks nicer, but even the original solution should
> not be that bad as it should be rarely used. What troubles me
> more is the possible infinite loop. Would you mind adding a
> timeout?
We already have a socket timeout, so I assume this is alrady
covered?
--
Eduardo
prev parent reply other threads:[~2018-06-08 18:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-06 19:27 [Qemu-devel] [RFC PATCH v2] qmp.py: Fix exception parsing partial JSON Philippe Mathieu-Daudé
2018-06-06 20:05 ` Eduardo Habkost
2018-06-06 23:06 ` Philippe Mathieu-Daudé
2018-06-08 17:57 ` Lukáš Doktor
2018-06-08 18:01 ` Eduardo Habkost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180608180139.GM7451@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=ldoktor@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.