From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 970D946970F
 for <tarantool-patches@dev.tarantool.org>;
 Sun, 24 Nov 2019 18:28:01 +0300 (MSK)
References: <cover.1574510839.git.imeevma@gmail.com>
 <84ae817b52e0d9415a0b89c730792b1e0221ff24.1574510839.git.imeevma@gmail.com>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <3deea5d5-cc8e-0943-1ad3-07ecc0263088@tarantool.org>
Date: Sun, 24 Nov 2019 16:27:58 +0100
MIME-Version: 1.0
In-Reply-To: <84ae817b52e0d9415a0b89c730792b1e0221ff24.1574510839.git.imeevma@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH v4 2/2] box: introduce
	_vsession_settings sysview
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: imeevma@tarantool.org
Cc: tarantool-patches@dev.tarantool.org

Hi! Thanks for the patch!

> diff --git a/src/box/session.cc b/src/box/session.cc
> index 461d1cf..93d8b42 100644
> --- a/src/box/session.cc
> +++ b/src/box/session.cc
> @@ -338,3 +341,131 @@ generic_session_sync(struct session *session)
> +
> +struct iterator *
> +session_options_create_iterator(struct index *index, enum iterator_type type,
> +				const char *key, uint32_t part_count)
> +{
> +	char *decoded_key = NULL;
> +	if (part_count > 0) {
> +		assert(part_count == 1);
> +		assert(mp_typeof(*key) == MP_STR);
> +		uint32_t len;
> +		const char *name = mp_decode_str(&key, &len);
> +		decoded_key = (char *)malloc(len + 1);
> +		if (decoded_key == NULL) {
> +			diag_set(OutOfMemory, len + 1, "malloc", "decoded_key");
> +			return NULL;
> +		}
> +		memcpy(decoded_key, name, len);
> +		decoded_key[len] = '\0';
> +	}
> +	struct space *space = space_cache_find(index->def->space_id);
> +	struct session_options_iterator *it =
> +		(session_options_iterator *)malloc(sizeof(*it));
> +	if (it == NULL) {

decoded_key leaks here. But heap OOM is such an unlikely event,
and is forgotten for be checked so often, that perhaps we should
reconsider moving this https://github.com/tarantool/tarantool/issues/3534
out of wish list and start using panic in new places. Probably
wrapped into a 'heap_alloc()' function (name is discussable).

I think, Kirill won't be against this.