Two comments:

1. Not sure if this is tier2, maybe it's tier3

2. The fix should be simple, ie. something like this:

diff --git a/monitor.c b/monitor.c
index a1ebc5d..b1880e0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4547,6 +4547,7 @@ static void monitor_control_event(void *opaque, int event)
         qobject_decref(data);
         break;
     case CHR_EVENT_CLOSED:
+        json_message_parser_flush(&mon->mc->parser);
         json_message_parser_destroy(&mon->mc->parser);
         break;
     }

But this causes a segfault, not sure why.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

I've tried the stupid solution for this one, but it didn't work. Not sure how
important this is now, as our parser will handle the input as soon as
it's a complete sentence.

I mean, some weeks ago clients would have to send a trailing space to make
our parser consume the input, like:

 { "execute": "system_reset" }\r

So, if the client closes the connection after sending '}' but before '\r',
the system_reset command wouldn't be executed. In this case, not flushing
the input is clearly visible as a bug, as QMP would just discard valid
input.

However, today (rhel6 & upstream) our parser will consume the input as soon as
it sees the '}' character.

Not sure this is a bug, will move it to rhel6.1 so that we can evaluate again in the future.

Recent changes in the parser (already backported to 6.0) makes this problem go away. It's true that QMP doesn't flush the input buffer on connection close, but valid input should be immediately handled when the last character of the input object is received.

Closing as not a bug.