Re: BUG #17920: Incorrect memory access in array_position(s) is detected (or not) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17920: Incorrect memory access in array_position(s) is detected (or not)
Date
Msg-id 3414186.1683215628@sss.pgh.pa.us
Whole thread Raw
In response to BUG #17920: Incorrect memory access in array_position(s) is detected (or not)  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #17920: Incorrect memory access in array_position(s) is detected (or not)
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



pgsql-bugs by date:

Previous
From: "BO ST"
Date:
Subject: Bug:Create a table with 1600 fields (reaching the upper limit), then drop several fields and create new ones, but the addition failed.
Next
From: "David G. Johnston"
Date:
Subject: Re: Bug:Create a table with 1600 fields (reaching the upper limit), then drop several fields and create new ones, but the addition failed.