From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Michael@gnu.org, qemu-devel@nongnu.org, Roth <mdroth@us.ibm.com>,
Markus Armbruster <armbru@redhat.com>
Subject: [Qemu-devel] Re: [PATCH 08/11] json-lexer: reset the lexer state on an invalid token
Date: Mon, 14 Mar 2011 17:12:43 -0300 [thread overview]
Message-ID: <20110314171243.4a44417d@doriath> (raw)
In-Reply-To: <4D7E6FF4.70503@us.ibm.com>
On Mon, 14 Mar 2011 14:43:48 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:
> On 03/14/2011 02:22 PM, Luiz Capitulino wrote:
> > On Fri, 11 Mar 2011 15:00:46 -0600
> > Anthony Liguori<aliguori@us.ibm.com> wrote:
> >
> >> Not everything handles errors from json parsing gracefully. By at least
> >> resetting the lexer, we'll start generating valid tokens again and hopefully
> >> recover the stream.
> >>
> >> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
> >>
> >> diff --git a/json-lexer.c b/json-lexer.c
> >> index c736f42..834d7af 100644
> >> --- a/json-lexer.c
> >> +++ b/json-lexer.c
> >> @@ -303,6 +303,9 @@ static int json_lexer_feed_char(JSONLexer *lexer, char ch)
> >> new_state = IN_START;
> >> break;
> >> case ERROR:
> >> + QDECREF(lexer->token);
> >> + lexer->token = qstring_new();
> >> + new_state = IN_START;
> >> return -EINVAL;
> > This makes the parser accept broken input like:
> >
> > { "execute": xxxxx }
> > {"return": {}}
>
> This is a bug in the current QMP server. Here's how my new QMP server
> responds:
>
> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 13, "major": 0},
> "package": ""}, "capabilities": []}}
> {"error": {"class": "JSONParseError", "data": {"message": "Missing value
> in dict"}}}
How do you handle it? Do you check the return of json_message_parser_feed()?
If that's the case, then the real problem in the current server is that we
use qemu's chardev interface and its read handler doesn't allow for
signaling errors. I did not consider not using it.
By looking at your branch I have the impression you wrote your own stuff,
am I right? If yes, doesn't it duplicate the chardev implementation?
>
> > { "execute": _ }
> > {"return": {}}
>
> Likewise, the new QMP server does not respond to this at all (which
> confuses me TBH).
>
> > Today, it handles this kind of input correctly:
> >
> > { "execute": xxxxx }
> > {"error": {"class": "JSONParsing", "desc": "Invalid JSON syntax", "data": {}}}
>
> The parser rejects this verses trying to get what it can out of it and
> passing that to QMP. The idea here is to be more graceful in dealing
> with bad input and trying to recover.
I'm all for trying to recover, but we can't have varied responses for
bad input. It seems easier to just fail.
>
> > Although it also accepts broken stuff today, like:
> >
> > { "execute": ___"query-block" }
>
> This is really the server, not the parser. The new server doesn't
> accept this.
This is probably the same as the xxxxx above.
> I guess QMP today just ignores the incoming QObject in capabilities mode
> and always returns {}. You'll see the same thing with:
>
> { "execute": "not-a-valid-command" }
> {"return": {}}
>
> But once you're in command mode, it does the right thing.
I can't reproduce it w/o this series applied:
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 14, "major": 0}, "package": ""}, "capabilities": []}}
{ "execute": "not-a-valid-command" }
{"error": {"class": "CommandNotFound", "desc": "The command not-a-valid-command has not been found", "data": {"name": "not-a-valid-command"}}}
next prev parent reply other threads:[~2011-03-14 20:12 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 21:00 [Qemu-devel] [00/11] QAPI Round 0 (JSON improvements) Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 01/11] Add hard build dependency on glib Anthony Liguori
2011-03-12 8:09 ` [Qemu-devel] " Paolo Bonzini
2011-03-12 14:52 ` Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 02/11] qerror: expose a function to format an error Anthony Liguori
2011-03-11 21:08 ` [Qemu-devel] " Anthony Liguori
2011-03-14 19:17 ` Luiz Capitulino
2011-03-14 19:27 ` Anthony Liguori
2011-03-14 19:37 ` Luiz Capitulino
2011-03-14 19:45 ` Anthony Liguori
2011-03-14 20:22 ` Luiz Capitulino
2011-03-14 20:41 ` Anthony Liguori
2011-03-14 20:48 ` Luiz Capitulino
2011-03-14 21:03 ` Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 03/11] add a generic Error object Anthony Liguori
2011-03-12 11:05 ` Blue Swirl
2011-03-12 14:51 ` Anthony Liguori
2011-03-14 19:18 ` [Qemu-devel] " Luiz Capitulino
2011-03-14 19:34 ` Anthony Liguori
2011-03-14 19:57 ` Luiz Capitulino
2011-03-11 21:00 ` [Qemu-devel] [PATCH 04/11] qerror: split out the reporting bits of QError Anthony Liguori
2011-03-14 19:18 ` [Qemu-devel] " Luiz Capitulino
2011-03-14 19:24 ` Anthony Liguori
2011-03-14 19:30 ` Luiz Capitulino
2011-03-14 20:30 ` Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 05/11] qerror: add new error message for invalid enum values Anthony Liguori
2011-03-14 19:19 ` [Qemu-devel] " Luiz Capitulino
2011-03-11 21:00 ` [Qemu-devel] [PATCH 06/11] qerror: add JSON parsing error message Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 07/11] json: propagate error from parser Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 08/11] json-lexer: reset the lexer state on an invalid token Anthony Liguori
2011-03-14 19:22 ` [Qemu-devel] " Luiz Capitulino
2011-03-14 19:43 ` Anthony Liguori
2011-03-14 20:12 ` Luiz Capitulino [this message]
2011-03-14 20:30 ` Anthony Liguori
2011-03-14 20:43 ` Luiz Capitulino
2011-03-11 21:00 ` [Qemu-devel] [PATCH 09/11] json-lexer: limit the maximum size of a given token Anthony Liguori
2011-03-14 19:25 ` [Qemu-devel] " Luiz Capitulino
2011-03-14 20:18 ` Anthony Liguori
2011-03-14 20:33 ` Luiz Capitulino
2011-03-11 21:00 ` [Qemu-devel] [PATCH 10/11] json-streamer: limit the maximum recursion depth and maximum token count Anthony Liguori
2011-03-11 23:16 ` Michael Roth
2011-03-12 15:03 ` Anthony Liguori
2011-03-11 21:00 ` [Qemu-devel] [PATCH 11/11] json-parser: detect premature EOI Anthony Liguori
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=20110314171243.4a44417d@doriath \
--to=lcapitulino@redhat.com \
--cc=Michael@gnu.org \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=mdroth@us.ibm.com \
--cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).