From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 793F325CC8 for ; Wed, 7 Aug 2019 14:26:02 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1XT4bwf0gIj for ; Wed, 7 Aug 2019 14:26:02 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id D941D209E8 for ; Wed, 7 Aug 2019 14:26:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: [tarantool-patches] Re: [PATCH v2 2/2] sql: fix error in case ARRAY/MAP converted to SCALAR From: "n.pettik" In-Reply-To: <20190727101643.GA10982@tarantool.org> Date: Wed, 7 Aug 2019 21:25:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67e721f4818f51861383cdf71cc88c63e45ab450.1563955619.git.imeevma@gmail.com> <20190727101643.GA10982@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Imeev Mergen >=20 > New patch: >=20 > =46rom 5dde6f6398ca9845c3a17173b9e9625bc1b20d32 Mon Sep 17 00:00:00 = 2001 > From: Mergen Imeev > Date: Mon, 22 Jul 2019 12:54:34 +0300 > Subject: [PATCH] sql: fix error in case ARRAY/MAP converted to SCALAR >=20 > Since ARRAY and MAP cannot be converted to a scalar, this > operation should throw an error. But when the error was throws > from SQL, the error was unreadable. The reason for this is that > the given array or map was not correctly converted to a string. > This patch fixes the problem by converting ARRAY or MAP to their > string representation. > For example: >=20 > box.execute('CREATE TABLE t1(i INT PRIMARY KEY, a SCALAR);') > format =3D {} > format[1] =3D {type =3D 'integer', name =3D 'I'} > format[2] =3D {type =3D 'array', name =3D 'A'} > s =3D box.schema.space.create('T2', {format=3Dformat}) > i =3D s:create_index('ii') > s:insert({1, {1,2,3}}) > box.execute('INSERT INTO t1 SELECT * FROM t2;') >=20 > Should return: > - error: 'Type mismatch: can not convert [1, 2, 3] to scalar' >=20 > Follow-up #4189 Fixed a bit commit message: sql: make valueToText() operate on MAP/ARRAY values =20 Since ARRAY and MAP cannot be converted to SCALAR type, this = operation should throw an error. But when the error is raised in SQL, it is displayed in unreadable form. The reason for this is that the given array or map is not correctly converted to a string. This patch = fixes the problem by converting ARRAY or MAP to their string = representation. For example: =20 box.execute('CREATE TABLE t1(i INT PRIMARY KEY, a SCALAR);') format =3D {} format[1] =3D {type =3D 'integer', name =3D 'I'} format[2] =3D {type =3D 'array', name =3D 'A'} s =3D box.schema.space.create('T2', {format=3Dformat}) i =3D s:create_index('ii') s:insert({1, {1,2,3}}) box.execute('INSERT INTO t1 SELECT * FROM t2;') =20 Should return: - error: 'Type mismatch: can not convert [1, 2, 3] to scalar' =20 Follow-up #4189 > diff --git a/src/box/sql/vdbemem.c b/src/box/sql/vdbemem.c > index 847a6b0..8bea46b 100644 > --- a/src/box/sql/vdbemem.c > +++ b/src/box/sql/vdbemem.c > @@ -1135,6 +1135,19 @@ valueToText(sql_value * pVal) > { > assert(pVal !=3D 0); > assert((pVal->flags & (MEM_Null)) =3D=3D 0); > + if ((pVal->flags & MEM_Subtype) !=3D 0 && > + pVal->subtype =3D=3D SQL_SUBTYPE_MSGPACK) { > + const char *value =3D mp_str(pVal->z); > + size_t len =3D strlen(value) + 1; > + char *result =3D region_alloc(&fiber()->gc, len); > + if (result =3D=3D NULL) { > + diag_set(OutOfMemory, len, "region_alloc", = "result"); > + sqlOomFault(sql_get()); > + return NULL; > + } > + memcpy(result, value, len); > + return result; That=E2=80=99s not what we need IMHO. Firstly, for all other memory = types =20 valueToText() function returns pVal->z, i.e. this function firstly = =20 converts value to string and then returns it. Secondly, we don=E2=80=99t = track =20 value allocated on region: obviously if it is used after transaction = =20 commitment, it will lead to use-after-free bug. I can=E2=80=99t say = whether this =20 scenario is possible looking only on code. You should rather patch = =20 sqlVdbeMemStringify: reserve memory using malloc, memcpy string to mem, = =20 change type of memory to MEM_Str. So that make it work with ARRAY and = =20 MAP types in the same way as with other types. = =20