Re: BUG #17920: Incorrect memory access in array_position(s) is detected (or not)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: exclusion(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17920: Incorrect memory access in array_position(s) is detected (or not)
Date: 2023-05-04 15:53:48
Message-ID: 3414186.1683215628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> When the following script:
> SELECT array_positions('{}'::int[], 1); SELECT array_positions('{}'::int[],
> 1)
> is executed under Valgrind, an incorrect memory access is detected:
> ==00:00:00:04.955 1823064== Invalid read of size 4

> ==00:00:00:04.955 1823064== at 0x5EDBD0: array_positions
> (array_userfuncs.c:806)

Fixed, thanks for the report!

> I was surprised by the fact, that Valgrind doesn't complain for the single
> query execution:
> SELECT array_positions('{}'::int[], 1)
> IIUC, this is explained by the lack of red zones around palloc'ed memory
> areas.
> sed "s/VALGRIND_CREATE_MEMPOOL(\(.*\), 0, false);/VALGRIND_CREATE_MEMPOOL(\1, 16, false);/" -i
> src/backend/utils/mmgr/mcxt.c
> on master (after 414d66220) helps Valgrind to detect the invalid read on
> the single query execution too:

I didn't try valgrind'ing this on HEAD, but I think this situation
might have been improved by 414d66220.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2023-05-04 16:12:31 Re: Bug:Create a table with 1600 fields (reaching the upper limit), then drop several fields and create new ones, but the addition failed.
Previous Message BO ST 2023-05-04 15:51:03 Bug:Create a table with 1600 fields (reaching the upper limit), then drop several fields and create new ones, but the addition failed.