pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
BUG #17874: Incorrect memory access at gistBuildCallback
5+ messages / 4 participants
[nested] [flat]

Commits from this thread:
  2023-03-29 8e5eef50c5 d2a1d4b190 b5c6776c11 2adb6adad5 2dc77adc76 a1904c9ce5  Fix dereference of dangling pointer in GiST index buffering build.
* BUG #17874: Incorrect memory access at gistBuildCallback
@ 2023-03-28 16:01  PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 1 reply; 5+ messages in thread

From: PG Bug reporting form @ 2023-03-28 16:01 UTC (permalink / raw)
  To: pgsql-bugs@lists.postgresql.org; +Cc: kyzevan23@mail.ru

The following bug has been logged on the website:

Bug reference:      17874
Logged by:          Egor Chindyaskin
Email address:      kyzevan23@mail.ru
PostgreSQL version: 15.2
Operating system:   Ubuntu 22.04
Description:        

With a server compiled with flag -DUSE_VALGRIND the following query:

create table test(a int4, b point);

create index test_index on test using gist(b) with (buffering = on,
fillfactor=50);
drop index test_index;
insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
10000) g;
vacuum analyze test;

create index test_index on test using gist(b) with (buffering = on,
fillfactor=50);
drop index test_index;
insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
10000) g;
vacuum analyze test;

create index test_index on test using gist(b) with (buffering = on,
fillfactor=50);
drop index test_index;
insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
10000) g;
vacuum analyze test;

create index test_index on test using gist(b) with (buffering = on,
fillfactor=50);
drop index test_index;
insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
10000) g;
vacuum analyze test;

causes an incorrect memory access:

==00:00:00:20.465 256552== Invalid read of size 2
==00:00:00:20.465 256552==    at 0x20EE4F: gistBuildCallback
(gistbuild.c:921)
==00:00:00:20.465 256552==    by 0x241838: heapam_index_build_range_scan
(heapam_handler.c:1794)
==00:00:00:20.465 256552==    by 0x20F308: table_index_build_scan
(tableam.h:1791)
==00:00:00:20.465 256552==    by 0x20F308: gistbuild (gistbuild.c:317)
==00:00:00:20.465 256552==    by 0x2DC8A9: index_build (index.c:3032)
==00:00:00:20.465 256552==    by 0x2DE3EC: index_create (index.c:1264)
==00:00:00:20.465 256552==    by 0x3946F5: DefineIndex (indexcmds.c:1164)
==00:00:00:20.465 256552==    by 0x5E6565: ProcessUtilitySlow
(utility.c:1552)
==00:00:00:20.465 256552==    by 0x5E593C: standard_ProcessUtility
(utility.c:1077)
==00:00:00:20.465 256552==    by 0x5E5A01: ProcessUtility (utility.c:530)
==00:00:00:20.465 256552==    by 0x5E2DDE: PortalRunUtility
(pquery.c:1158)
==00:00:00:20.465 256552==    by 0x5E30DB: PortalRunMulti (pquery.c:1315)
==00:00:00:20.465 256552==    by 0x5E34DD: PortalRun (pquery.c:791)
==00:00:00:20.465 256552==  Address 0xeab8f1e is 382 bytes inside a block of
size 8,192 alloc'd
==00:00:00:20.465 256552==    at 0x4848899: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:00:20.465 256552==    by 0x74FFAD: AllocSetContextCreateInternal
(aset.c:446)
==00:00:00:20.465 256552==    by 0x7383F2: hash_create (dynahash.c:385)
==00:00:00:20.465 256552==    by 0x20F852: gistInitBuildBuffers
(gistbuildbuffers.c:82)
==00:00:00:20.465 256552==    by 0x20D5AE: gistInitBuffering
(gistbuild.c:833)
==00:00:00:20.465 256552==    by 0x20EF09: gistBuildCallback
(gistbuild.c:955)
==00:00:00:20.465 256552==    by 0x241838: heapam_index_build_range_scan
(heapam_handler.c:1794)
==00:00:00:20.465 256552==    by 0x20F308: table_index_build_scan
(tableam.h:1791)
==00:00:00:20.465 256552==    by 0x20F308: gistbuild (gistbuild.c:317)
==00:00:00:20.465 256552==    by 0x2DC8A9: index_build (index.c:3032)
==00:00:00:20.465 256552==    by 0x2DE3EC: index_create (index.c:1264)
==00:00:00:20.465 256552==    by 0x3946F5: DefineIndex (indexcmds.c:1164)
==00:00:00:20.465 256552==    by 0x5E6565: ProcessUtilitySlow
(utility.c:1552)
==00:00:00:20.465 256552== 
{
   <insert_a_suppression_name_here>
   Memcheck:Addr2
   fun:gistBuildCallback
   fun:heapam_index_build_range_scan
   fun:table_index_build_scan
   fun:gistbuild
   fun:index_build
   fun:index_create
   fun:DefineIndex
   fun:ProcessUtilitySlow
   fun:standard_ProcessUtility
   fun:ProcessUtility
   fun:PortalRunUtility
   fun:PortalRunMulti
   fun:PortalRun
}
==00:00:00:20.465 256552== 
==00:00:00:20.465 256552== Exit program on first error
(--exit-on-first-error=yes)

This issue reproduces on all supported branches.



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: BUG #17874: Incorrect memory access at gistBuildCallback
@ 2023-03-29 10:00  Alexander Lakhin <exclusion@gmail.com>
  parent: PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 1 reply; 5+ messages in thread

From: Alexander Lakhin @ 2023-03-29 10:00 UTC (permalink / raw)
  To: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org

Hi Egor,

28.03.2023 19:01, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17874
> Logged by:          Egor Chindyaskin
> Email address:      kyzevan23@mail.ru
> PostgreSQL version: 15.2
> Operating system:   Ubuntu 22.04
> Description:
>
> With a server compiled with flag -DUSE_VALGRIND the following query:
>
> create table test(a int4, b point);
>
> create index test_index on test using gist(b) with (buffering = on,
> fillfactor=50);
> drop index test_index;
> insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
> 10000) g;
> vacuum analyze test;
>
> ...
>
> causes an incorrect memory access:
>
> ==00:00:00:20.465 256552== Invalid read of size 2
> ==00:00:00:20.465 256552==    at 0x20EE4F: gistBuildCallback
> (gistbuild.c:921)
> ...
>
> This issue reproduces on all supported branches.

That issue was reported already as bug #16329:
https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org

Maybe it's worth to register the fix proposed there for the next commitfest...

Best regards,
Alexander





^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: BUG #17874: Incorrect memory access at gistBuildCallback
@ 2023-03-29 10:11  Daniel Gustafsson <daniel@yesql.se>
  parent: Alexander Lakhin <exclusion@gmail.com>
  0 siblings, 1 reply; 5+ messages in thread

From: Daniel Gustafsson @ 2023-03-29 10:11 UTC (permalink / raw)
  To: Alexander Lakhin <exclusion@gmail.com>; +Cc: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org

> On 29 Mar 2023, at 12:00, Alexander Lakhin <exclusion@gmail.com> wrote:

> That issue was reported already as bug #16329:
> https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
> 
> Maybe it's worth to register the fix proposed there for the next commitfest...

Summarizing that thread and registering the proposed patch for the next
commitfest seems like the right thing to do.

--
Daniel Gustafsson






^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: BUG #17874: Incorrect memory access at gistBuildCallback
@ 2023-03-29 11:47  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Daniel Gustafsson <daniel@yesql.se>
  0 siblings, 1 reply; 5+ messages in thread

From: Tom Lane @ 2023-03-29 11:47 UTC (permalink / raw)
  To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Alexander Lakhin <exclusion@gmail.com>; kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org

Daniel Gustafsson <daniel@yesql.se> writes:
>> On 29 Mar 2023, at 12:00, Alexander Lakhin <exclusion@gmail.com> wrote:
>> That issue was reported already as bug #16329:
>> https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
>> Maybe it's worth to register the fix proposed there for the next commitfest...

> Summarizing that thread and registering the proposed patch for the next
> commitfest seems like the right thing to do.

Yeah.  We did fix the lack of test coverage that much of that thread
was about, but it seems like we forgot the original bug (which I
guess indicates that the coverage is still inadequate, since the
valgrind buildfarm animals haven't noticed it...)

			regards, tom lane





^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: BUG #17874: Incorrect memory access at gistBuildCallback
@ 2023-03-29 15:40  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 5+ messages in thread

From: Tom Lane @ 2023-03-29 15:40 UTC (permalink / raw)
  To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Alexander Lakhin <exclusion@gmail.com>; kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org

I wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Summarizing that thread and registering the proposed patch for the next
>> commitfest seems like the right thing to do.

> Yeah.

I went ahead and reviewed/pushed this, so nevermind about a CF entry.

			regards, tom lane





^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2023-03-29 15:40 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-03-28 16:01 BUG #17874: Incorrect memory access at gistBuildCallback PG Bug reporting form <noreply@postgresql.org>
2023-03-29 10:00 ` Alexander Lakhin <exclusion@gmail.com>
2023-03-29 10:11   ` Daniel Gustafsson <daniel@yesql.se>
2023-03-29 11:47     ` Tom Lane <tgl@sss.pgh.pa.us>
2023-03-29 15:40       ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox