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
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. |