Re: BUG #17912: Invalid memory access when converting plpython' array containing empty array

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17912: Invalid memory access when converting plpython' array containing empty array
Date: 2023-05-04 13:27:49
Message-ID: 3206590.1683206869@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> 30.04.2023 19:24, Tom Lane wrote:
>> Here's a version that adopts plperl's logic, causing it to treat
>> empty sub-lists as being zero-length dimensions. Most of the new
>> test cases are borrowed from plperl, too, and most of them act
>> differently before and after the code change. So I'm pretty
>> hesitant to put this into stable branches. OTOH, maybe it's not
>> too late for v16?

> Thanks for the patch!
> I've tested the new implementation and found no issues with it — only
> rectangular structures are accepted now. The code is straightforward and
> very similar to plperl's, so I would not expect that it might bring new
> anomalies, which couldn't be seen before.
> Thus I don't think that adding it to current master (and possible follow-up
> fixing) can take a significant amount of time out of v16+ schedule only.

After thinking about this some more, I'm inclined to go ahead and
apply this patch and indeed back-patch it. As things stood before
commits 81eaaf65e et al, it was completely unsafe to use an empty
first-level sub-list in a plpython multi-dimensional result value at all.
The only valid use of such a thing would be like "return [[], []]",
that is, all the sub-lists have to be zero-length to satisfy
rectangularity. So that would trigger the bug you originally reported
wherein a zero-length first sublist computes a wrong datum array
length leading to memory clobber. Commit 81eaaf65e did the minimum
possible change to stop the memory clobber, but it left us in a
situation where the actual result behavior isn't very sane. We
should not ship that behavior; we should make it do something sane,
namely return a zero-dimensional array for cases like this.

The argument against that is that zero-length sublists below the
first level managed not to crash, nor to fail, in some weird
cases like this one:

regression=# CREATE OR REPLACE FUNCTION test_type_conversion_md_array_out() RETURNS text[] AS $$
regression$# return [[1], [[]]]
regression$# $$ LANGUAGE plpython3u;
CREATE FUNCTION
regression=# select test_type_conversion_md_array_out();
test_type_conversion_md_array_out
-----------------------------------
{{1},{[]}}
(1 row)

which the patch would turn into an error case. But it's pretty hard
to believe that anyone is depending on corner cases like that one
and yet managing not to trip over the crash hazard. Moreover,
throwing an error for this is consistent with the change we made
in plperl at f47004add et al. So I'm thinking let's apply this
patch and then just release-note all three patchsets as "tighten
checks for rectangularity of multi-dimensional arrays in plperl
and plpython".

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-05-04 15:26:58 Re: BUG #17912: Invalid memory access when converting plpython' array containing empty array
Previous Message PG Bug reporting form 2023-05-04 13:00:00 BUG #17920: Incorrect memory access in array_position(s) is detected (or not)