Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls
Date: 2023-03-22 03:07:15
Message-ID: CAMbWs4_=kd4-u3Mh3tV+NcHuSGY-9Fax+Ck1ZVzOV0HzJ6dXow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Mar 21, 2023 at 10:24 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> > 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):
>
> In that case, won't padding bytes between array elements also create
> issues? Seems like we have to just zero the whole array area, like
> those other functions do.

Yeah, this should be the right fix, to use palloc0 instead here. FWIW
currently in the codes there are 14 places that explicitly allocate
ArrayType, 13 of them using palloc0, the only exception is the one
discussed here.

BTW, in array_set_slice() and array_set_element() we explicitly zero the
null bitmap although the whole array area is allocated with palloc0. Is
this necessary?

Thanks
Richard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2023-03-22 06:18:47 Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
Previous Message Tom Lane 2023-03-21 14:24:28 Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls