Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1soM9C-00Aao8-VZ for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2024 12:08:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1soM9C-00GA4L-Gu for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2024 12:08:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1soM9B-00GA4A-5W for pgsql-hackers@lists.postgresql.org; Wed, 11 Sep 2024 12:08:34 +0000 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1soM97-000dAs-Nx for pgsql-hackers@lists.postgresql.org; Wed, 11 Sep 2024 12:08:31 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 7DBC1FF80E; Wed, 11 Sep 2024 12:08:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1726056505; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yf/a5ijI8vQlAEEs3yZhXuZpxLkgUSLSe9MsB5KeKxY=; b=Wujoy0uq2oAhVdUBhn2wEJhFG2qJ0jcGKBdq6HIozL7M+7oHxHCp5zQYTiOirwdJDEJnHk B8ylIQOrq8bAZcNCPsPgMFV3CIYqDQ2aFS6VO8eoua9chuExhOcMDfyCcdMMIjtaYBU9sx njnjj/nXpnwZyFE55a5SvDbb5wSJgaH++JPsrz4fkddmNEzQeGvJOjplPoDuA3XCq/Soka 5HRGZ6aUHLvUjycjvpXXjpg8/g0QRTBH7eOFIvvr3i4BiMinqTBI6panbu4/+2a7AFoO0u ZpfZZwY3r8PH4rP9WKIqqNncEgj5BTnxlLaVa+8KXj1oLz0QUSE1EzybBaa/fQ== Message-ID: Date: Wed, 11 Sep 2024 14:08:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18598: AddressSanitizer detects use after free inside json_unique_hash_match() From: Tomas Vondra To: Junwang Zhao Cc: exclusion@gmail.com, PostgreSQL Hackers References: <18598-3279ed972a2347c7@postgresql.org> <98481f61-abf6-46df-8e83-82f6ff66cefb@vondra.me> <974b94bb-45a7-4472-9826-c2323f40228a@vondra.me> <4dd0cac2-d008-404c-bf03-bea532315b2e@vondra.me> Content-Language: en-US In-Reply-To: <4dd0cac2-d008-404c-bf03-bea532315b2e@vondra.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/10/24 21:47, Tomas Vondra wrote: > ... > > The only question that bothers me a little bit is the possibility of a > memory leak - could it happen that we keep the copied key much longer > than needed? Or does aggcontext have with the right life span? AFAICS > that's where we allocate the aggregate state, so it seems fine. > > Also, how far back do we need to backpatch this? ITSM PG15 does not have > this issue, and it was introduced with the SQL/JSON stuff in PG16. Is > that correct? > Nah, I spent a bit of time looking for a memory leak, but I don't think there's one, or at least not a new one. We use the same memory context as for the hash table / buffer, so that should be fine. But this made me realize the code in json_build_object_worker() can simply use pstrdup() to copy the key into CurrentMemoryContext, which is where the hash table of unique keys is. In fact, using unique_check.mcxt would not be quite right: MemoryContext mcxt; /* context for saving skipped keys */ And this has nothing to do with skipped keys. So I adjusted that way and pushed. Thanks for the report / patch. -- Tomas Vondra