From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzs9G-0004qw-5e for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:19:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zzs9B-0003pk-8i for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:19:10 -0500 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:35162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzs9B-0003pg-2D for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:19:05 -0500 Received: by wmdw130 with SMTP id w130so33109196wmd.0 for ; Fri, 20 Nov 2015 12:19:04 -0800 (PST) Sender: Paolo Bonzini References: <1448010269-21694-1-git-send-email-pbonzini@redhat.com> <1448010269-21694-5-git-send-email-pbonzini@redhat.com> <564F6B17.5040201@redhat.com> From: Paolo Bonzini Message-ID: <564F8036.6010905@redhat.com> Date: Fri, 20 Nov 2015 21:19:02 +0100 MIME-Version: 1.0 In-Reply-To: <564F6B17.5040201@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] qjson: surprise, allocating 6 QObjects per token is expensive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: armbru@redhat.com On 20/11/2015 19:48, Eric Blake wrote: >> > + token = g_malloc(sizeof(JSONToken) + input->len + 1); >> > + token->type = type; >> > + memcpy(token->str, input->str, input->len + 1); >> > + token->str[input->len] = 0; > Looks like you are writing the last byte twice. Either the +1 in the > memcpy() always copies a NUL byte and we don't need the second > assignment, or you should drop the +1. > > Otherwise, looks like a sane replacement that saves a lot of memory. You're right. The memcpy is wrong and reads out of bounds. Paolo > Reviewed-by: Eric Blake > > Are we hoping to get this in 2.5 because it fixes the memory hog bug, or > are we considering that it is not a regression from 2.4 and therefore > something that should wait for 2.6?