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 1pebaz-0006xr-CX for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Mar 2023 13:00:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pebax-0006ca-BS for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Mar 2023 13:00:07 +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 1pebax-0006cP-0I for pgsql-bugs@lists.postgresql.org; Tue, 21 Mar 2023 13:00:07 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pebau-0006Re-J5 for pgsql-bugs@lists.postgresql.org; Tue, 21 Mar 2023 13:00:06 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 20so8261310lju.0 for ; Tue, 21 Mar 2023 06:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679403603; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=Xli36Gq0dCiyq/ik18Yx/GqcXj4uMeO2h012dKmDs3g=; b=HTdy+kGQIYt8X+7f9+BmHh9tOZQgJf6ynceZ/wvOd6P0MIen97UZ9gAsRdBm8HC0qD lECdKUhzMIQzwdw6w0t6JZhbaGd7UYpqsR8zEN1MVk/5lLS2RyvsRX0Ys0BHC0Znigco YNJ6PCy0LauCqhCCNBD86jj7xLOz4ULn8Fi/XQaRKIr5+fLRqpuaucD8jM/qr56WiN63 KCwYpxQ+4d62gOlZhQiZRZHChnQx4PFEcYjMo6RiuMkq95n3qr/CLM6AkBmllUb+yD+F y1ZHrKChvI/w2QVGDDhGpPPkmVzn+XEg3lWG6Y9W4SOjs50SYtlfXn0GlTyFwa/33gBB S/yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679403603; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Xli36Gq0dCiyq/ik18Yx/GqcXj4uMeO2h012dKmDs3g=; b=Xz2nb+l7MjPeERPfykU4BIQ33onUcA+mKfC5pvHYLFT65E1sahzwL1QKUgVnRhZia1 j1FTJPC9C0uYF9TxAUlnVqHjahT/uH3+7weeBQzFQ4R+inUgxoldSWC1kcNlM5TqlrSV THUUnZZhetqmhVWHBXxLd+gI89UJrEM44ebclxWkpiyVfY7uw4+FitmXd80trh+P8VgK qaLQYBtsr8D+QjGTjhlNjLK9Bc/jcasde8rhB9t5mA8viRrbuBKJa5TbD+Q8POB0u4P2 dwhzpVjC3Dt/c6xmR8fBu92d6UBk3zCKH0dUcuFNjL9AD+mVbHICPVpM+WS7yhQ3YkwT sDpg== X-Gm-Message-State: AO0yUKWbgB02pRbDcgOksytowitzZOi+RV4jJlsYM48IuprfND7r5Hb1 OB03imPqthSKH98F7I7zZmMRy7NX4NU= X-Google-Smtp-Source: AK7set+IuJivEnLuxClJcUN574mnCpyQEuW/U3VkYLCSvrSjCZMj7TW03AMIf7ArVEBmot6vgVkuvw== X-Received: by 2002:a2e:9d15:0:b0:29e:4fa5:1708 with SMTP id t21-20020a2e9d15000000b0029e4fa51708mr830184lji.3.1679403602709; Tue, 21 Mar 2023 06:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.98]) by smtp.gmail.com with ESMTPSA id u22-20020ac24c36000000b004e80141709fsm2145600lfq.109.2023.03.21.06.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Mar 2023 06:00:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------VJOPgXjJsm0nTK6FcYMcRQQ4" Message-ID: <4240d86f-7e9f-388b-fd96-f8944860c0f5@gmail.com> Date: Tue, 21 Mar 2023 16: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: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls Content-Language: en-US To: Richard Guo , pgsql-bugs@lists.postgresql.org References: <17858-8fd287fd3663d051@postgresql.org> From: Alexander Lakhin 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. --------------VJOPgXjJsm0nTK6FcYMcRQQ4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Richard, 21.03.2023 14:52, Richard Guo wrote: > Nice catch.  This can also be seen on master. > > I searched the codes a little bit and found that in array_set_slice() > and array_set_element() the 'newarray' is allocated with palloc0 and > then the nulls bitmap is zeroed with > >  MemSet(nullbitmap, 0, (nitems + 7) / 8); > > if havenulls is true.  I wonder if we can do the same here. I'm afraid that zeroing only bytes behind nitems bits is not enough, as outDatum() doesn't bother to calculate the exact size of nulls bitmap, it just outputs all bytes of a datum (40 bytes in that case):    length = datumGetSize(value, typbyval, typlen); ...             for (i = 0; i < length; i++)                appendStringInfo(str, "%d ", (int) (s[i])); Best regards, Alexander --------------VJOPgXjJsm0nTK6FcYMcRQQ4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Richard,
21.03.2023 14:52, Richard Guo wrote:
Nice catch.  This can also be seen on master.

I searched the codes a little bit and found that in array_set_slice()
and array_set_element() the 'newarray' is allocated with palloc0 and
then the nulls bitmap is zeroed with

 MemSet(nullbitmap, 0, (nitems + 7) / 8);

if havenulls is true.  I wonder if we can do the same here.

I'm afraid that zeroing only bytes behind nitems bits is not enough, as outDatum() doesn't bother to calculate the exact size of nulls bitmap, it just outputs all bytes of a datum (40 bytes in that case):
   length = datumGetSize(value, typbyval, typlen);
...
            for (i = 0; i < length; i++)
               appendStringInfo(str, "%d ", (int) (s[i]));

Best regards,
Alexander
--------------VJOPgXjJsm0nTK6FcYMcRQQ4--