Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRVd7-0003m9-2e for pgsql-bugs@arkaria.postgresql.org; Mon, 13 Feb 2023 10:00:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pRVd5-0000AI-VX for pgsql-bugs@arkaria.postgresql.org; Mon, 13 Feb 2023 10:00:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRVd5-0000A8-In for pgsql-bugs@lists.postgresql.org; Mon, 13 Feb 2023 10:00:11 +0000 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pRVcz-00004u-39 for pgsql-bugs@lists.postgresql.org; Mon, 13 Feb 2023 10:00:10 +0000 Received: by mail-ed1-x52f.google.com with SMTP id v13so12016278eda.11 for ; Mon, 13 Feb 2023 02:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-language:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=A8ecq49GfkPZJ8KHApzqG8hmpYJUaW7THcpp+0Fk9hg=; b=TVjxOXP+s5Xaz/DYSPh9vBFNCuaJqUMKnlZEFm1/+RDx912wKrVICWq75J1ilS5+WZ K+N611tRXQ9XhpI0v20sSlS2CV8XHsYTWlFeBaBkGGD3/bzSPH9kBds/1RRSyp3+fRFR ezc/zNtLeAm3tto76NY+XebDKB7A5T9T52mbpVqDC9ZWxDi1s0klWqZRjayT5QVVVp5Y 3vdTEzp1f7HmX8nzhc/NomQGja+D0L2os3D4n8TI+yvYyN7mcGlF+dmJlJ656zoZLIHV eDJuNogDbop5H7fs14YxHdiJma4Fm96cJ+XZkocAR2Sw33kQyHvVMJHBA5Jvaun2pBWX D5Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-language:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=A8ecq49GfkPZJ8KHApzqG8hmpYJUaW7THcpp+0Fk9hg=; b=BLkcKYQoDJf8w6ZxRKbUjw5ZnV0C6lbqqOde5WzrTtmXKZIW/DkKaFPfieozacXSyo MfODWAnNt2Pusr0FaiQ/YsPWGKYnUYDdq3WdPUpXGwGHAArmLVKJp9UCKHMAbFX/t8n1 eji0HB93CrRZslFzYnL9vx7SCWjV0c8jRX3cC784Xg/5R3nYvtm0zZT0kqUorjOtve8G dnUpc2b8oI4UUgN58sMgCQXtIc3HLsq0TVk9hDddIG6sG2trefUQ6GSdL6eo1tBqLNjN K4DPDwRLSamujOt9TiD4rda4bn58Nl/+z+rF7gk2VYaabimgt1Sh80+ecBrnGiOUrh+Q tI3g== X-Gm-Message-State: AO0yUKVofPZE8czL5F6GgGkGb7epbvN1rDgqTYUU96XWawcugzzFMMUJ k2vnw33gRwEKxbkKU4Hv2kI= X-Google-Smtp-Source: AK7set+Q1qmcSP6Wy7XcdJ+fG1kjXdiQUavP/f9pGy094qkUXiN7DEu/G6k84cbFBdKljgabX+wUmA== X-Received: by 2002:a50:d644:0:b0:4ac:c9d8:d74d with SMTP id c4-20020a50d644000000b004acc9d8d74dmr1638990edj.25.1676282402747; Mon, 13 Feb 2023 02:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.5.191]) by smtp.gmail.com with ESMTPSA id w9-20020a50d789000000b004aacee2728dsm6363400edi.19.2023.02.13.02.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 02:00:01 -0800 (PST) Content-Type: multipart/alternative; boundary="------------5hu4UE4Uv0fp0z7CM9Ni0e2t" Message-ID: <4103db46-d888-6d1d-e88d-87c21ed99472@gmail.com> Date: Mon, 13 Feb 2023 13:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: array_agg(DISTINCT) caused a segmentation fault To: David Rowley , Fujii Masao Cc: pgsql-bugs@lists.postgresql.org References: <860c6d6f-a3c5-3ae9-9da2-827177bede06@oss.nttdata.com> From: Alexander Lakhin Content-Language: en-US In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------5hu4UE4Uv0fp0z7CM9Ni0e2t Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello David, 13.02.2023 10:44, David Rowley wrote: > On Mon, 13 Feb 2023 at 18:29, Fujii Masao wrote: >> =# SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge; >> LOG: server process (PID 76507) was terminated by signal 11: Segmentation fault: 11 >> DETAIL: Failed process was running: SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge; > I've now pushed a fix for it and included your test. To get it to > crash it needed to be a byref aggregate without a strict transition > function. There are not too many of those, which is probably why > nobody noticed this before. I've encountered an issue that could have the same title but it still reproduced after the fix. The following query: SELECT array_agg(DISTINCT a ORDER BY a DESC)           FROM (VALUES (1),(1.0),(NULL)) v(a); Invokes valgrind-detected error: ==00:00:00:03.708 2686358== Invalid read of size 4 ==00:00:00:03.708 2686358==    at 0x76C4AE: GetMemoryChunkMethodID (mcxt.c:195) ==00:00:00:03.708 2686358==    by 0x76C4AE: pfree (mcxt.c:1439) ==00:00:00:03.708 2686358==    by 0x3FD547: ExecEvalPreOrderedDistinctSingle (execExprInterp.c:4258) ==00:00:00:03.708 2686358==    by 0x3FF203: ExecInterpExpr (execExprInterp.c:1772) ==00:00:00:03.708 2686358==    by 0x418792: ExecEvalExprSwitchContext (executor.h:344) ==00:00:00:03.708 2686358==    by 0x418792: advance_aggregates (nodeAgg.c:823) ==00:00:00:03.708 2686358==    by 0x41A12A: agg_retrieve_direct (nodeAgg.c:2446) ==00:00:00:03.708 2686358==    by 0x41A294: ExecAgg (nodeAgg.c:2171) ==00:00:00:03.708 2686358==    by 0x40AD3F: ExecProcNodeFirst (execProcnode.c:464) ==00:00:00:03.708 2686358==    by 0x40337F: ExecProcNode (executor.h:262) ==00:00:00:03.708 2686358==    by 0x40337F: ExecutePlan (execMain.c:1633) ==00:00:00:03.708 2686358==    by 0x403542: standard_ExecutorRun (execMain.c:364) ==00:00:00:03.708 2686358==    by 0x40360E: ExecutorRun (execMain.c:308) ==00:00:00:03.708 2686358==    by 0x5EB971: PortalRunSelect (pquery.c:924) ==00:00:00:03.708 2686358==    by 0x5ED31B: PortalRun (pquery.c:768) ==00:00:00:03.708 2686358==  Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd ==00:00:00:03.708 2686358== ... ==00:00:00:03.708 2686358== ==00:00:00:03.708 2686358== Exit program on first error (--exit-on-first-error=yes) 2023-02-13 10:26:39.276 MSK [2686332] LOG:  server process (PID 2686358) exited with exit code 1 2023-02-13 10:26:39.276 MSK [2686332] DETAIL:  Failed process was running: SELECT array_agg(DISTINCT a ORDER BY a DESC)               FROM (VALUES (1),(1.0),(NULL)) v(a); (Without valgrind I get SIGSEGV here.) The first bad commit is 1349d2790 again (but before 80ef92675 an assertion failure can be seen). Best regards, Alexander --------------5hu4UE4Uv0fp0z7CM9Ni0e2t Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello David,

13.02.2023 10:44, David Rowley wrote:
On Mon, 13 Feb 2023 at 18:29, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
=# SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge;
LOG:  server process (PID 76507) was terminated by signal 11: Segmentation fault: 11
DETAIL:  Failed process was running: SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge;
I've now pushed a fix for it and included your test.  To get it to
crash it needed to be a byref aggregate without a strict transition
function.  There are not too many of those, which is probably why
nobody noticed this before.
I've encountered an issue that could have the same title but it still reproduced after the fix.
The following query:
SELECT array_agg(DISTINCT a ORDER BY a DESC)
          FROM (VALUES (1),(1.0),(NULL)) v(a);

Invokes valgrind-detected error:
==00:00:00:03.708 2686358== Invalid read of size 4
==00:00:00:03.708 2686358==    at 0x76C4AE: GetMemoryChunkMethodID (mcxt.c:195)
==00:00:00:03.708 2686358==    by 0x76C4AE: pfree (mcxt.c:1439)
==00:00:00:03.708 2686358==    by 0x3FD547: ExecEvalPreOrderedDistinctSingle (execExprInterp.c:4258)
==00:00:00:03.708 2686358==    by 0x3FF203: ExecInterpExpr (execExprInterp.c:1772)
==00:00:00:03.708 2686358==    by 0x418792: ExecEvalExprSwitchContext (executor.h:344)
==00:00:00:03.708 2686358==    by 0x418792: advance_aggregates (nodeAgg.c:823)
==00:00:00:03.708 2686358==    by 0x41A12A: agg_retrieve_direct (nodeAgg.c:2446)
==00:00:00:03.708 2686358==    by 0x41A294: ExecAgg (nodeAgg.c:2171)
==00:00:00:03.708 2686358==    by 0x40AD3F: ExecProcNodeFirst (execProcnode.c:464)
==00:00:00:03.708 2686358==    by 0x40337F: ExecProcNode (executor.h:262)
==00:00:00:03.708 2686358==    by 0x40337F: ExecutePlan (execMain.c:1633)
==00:00:00:03.708 2686358==    by 0x403542: standard_ExecutorRun (execMain.c:364)
==00:00:00:03.708 2686358==    by 0x40360E: ExecutorRun (execMain.c:308)
==00:00:00:03.708 2686358==    by 0x5EB971: PortalRunSelect (pquery.c:924)
==00:00:00:03.708 2686358==    by 0x5ED31B: PortalRun (pquery.c:768)
==00:00:00:03.708 2686358==  Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd
==00:00:00:03.708 2686358==
...
==00:00:00:03.708 2686358==
==00:00:00:03.708 2686358== Exit program on first error (--exit-on-first-error=yes)
2023-02-13 10:26:39.276 MSK [2686332] LOG:  server process (PID 2686358) exited with exit code 1
2023-02-13 10:26:39.276 MSK [2686332] DETAIL:  Failed process was running: SELECT array_agg(DISTINCT a ORDER BY a DESC)
              FROM (VALUES (1),(1.0),(NULL)) v(a);

(Without valgrind I get SIGSEGV here.)
The first bad commit is 1349d2790 again (but before 80ef92675 an assertion failure can be seen).

Best regards,
Alexander
--------------5hu4UE4Uv0fp0z7CM9Ni0e2t--