pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17995: Segmentation fault caused by UPDATE statement
8+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2023-06-24 691594acd6 3b4580f5ce c7f33a197b b6ab18a990 a77d901714 4c61afa47c Check for interrupts and stack overflow in TParserGet().
* BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-24 18:33 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 8+ messages in thread
From: PG Bug reporting form @ 2023-06-24 18:33 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: zuming.jiang@inf.ethz.ch
The following bug has been logged on the website:
Bug reference: 17995
Logged by: Zuming Jiang
Email address: zuming.jiang@inf.ethz.ch
PostgreSQL version: 16beta1
Operating system: Ubuntu 20.04
Description:
My fuzzer finds a bug in Postgres, which crashes Postgres. This bug can be
reproduced even after applying the fixing patches for
https://www.postgresql.org/message-id/flat/b2bd02dff61af15e3526293e2771f874cf2a3be7.camel@cybertec.a...
--- Test case ---
create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);
---
--- Expected behavior ---
Postgres does not crash.
--- Actual behavior ---
Postgres crashes.
--- Server log ---
2023-06-24 18:27:12.606 UTC [36] LOG: server process (PID 3917180) was
terminated by signal 11: Segmentation fault
2023-06-24 18:27:12.606 UTC [36] DETAIL: Failed process was running: update
t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey)
2023-06-24 18:27:12.606 UTC [36] LOG: terminating any other active server
processes
2023-06-24 18:27:12.607 UTC [36] LOG: all server processes terminated;
reinitializing
2023-06-24 18:27:12.658 UTC [3917181] LOG: database system was interrupted;
last known up at 2023-06-24 18:27:11 UTC
2023-06-24 18:27:22.848 UTC [3917181] LOG: database system was not properly
shut down; automatic recovery in progress
---
--- Postgres version ---
Github commit: f5c446e3367527f9db1506d7c38d2f56e20950b6
Version: PostgreSQL 16beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit
--- Platform information ---
Platform: Ubuntu 20.04
Kernel: Linux 5.4.0-147-generic
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-24 19:51 Tom Lane <tgl@sss.pgh.pa.us>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 2 replies; 8+ messages in thread
From: Tom Lane @ 2023-06-24 19:51 UTC (permalink / raw)
To: zuming.jiang@inf.ethz.ch; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> --- Test case ---
> create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
> insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
> update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);
Hmm, I don't think this is about the UPDATE per se, it's about
not having a stack depth check in TParserGet() :-(
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-24 20:48 Willian Colognesi <willian_colognesi@trimble.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 8+ messages in thread
From: Willian Colognesi @ 2023-06-24 20:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: zuming.jiang@inf.ethz.ch; pgsql-bugs@lists.postgresql.org
A time ago I had a problem with segmentation fault, and it was solved
disabling jit.
On Sat, Jun 24, 2023, 16:52 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > --- Test case ---
> > create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
> > insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
> > update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);
>
> Hmm, I don't think this is about the UPDATE per se, it's about
> not having a stack depth check in TParserGet() :-(
>
> regards, tom lane
>
>
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-25 03:00 Alexander Lakhin <exclusion@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 8+ messages in thread
From: Alexander Lakhin @ 2023-06-25 03:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; zuming.jiang@inf.ethz.ch; +Cc: pgsql-bugs@lists.postgresql.org
Hello,
24.06.2023 22:51, Tom Lane wrote:
> Hmm, I don't think this is about the UPDATE per se, it's about
> not having a stack depth check in TParserGet() :-(
BTW, there is a commitfest entry to eliminate a bunch of other stack
overflow hazards (may be the fuzzer can find some of them too):
https://commitfest.postgresql.org/43/4239/
(It looks like this issue was not discovered there because TParserGet()
doesn't call itself directly.)
Best regards,
Alexander
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-26 04:21 Michael Paquier <michael@paquier.xyz>
parent: Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Michael Paquier @ 2023-06-26 04:21 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; zuming.jiang@inf.ethz.ch; pgsql-bugs@lists.postgresql.org
On Sun, Jun 25, 2023 at 06:00:00AM +0300, Alexander Lakhin wrote:
> BTW, there is a commitfest entry to eliminate a bunch of other stack
> overflow hazards (may be the fuzzer can find some of them too):
> https://commitfest.postgresql.org/43/4239/
Thanks for the pointer, I'll double-check that. Some of the locations
of stack depth checks proposed involve performance-sensitive code
paths, though, like mcxt.c :/
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-26 04:27 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 2 replies; 8+ messages in thread
From: Tom Lane @ 2023-06-26 04:27 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Alexander Lakhin <exclusion@gmail.com>; zuming.jiang@inf.ethz.ch; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Jun 25, 2023 at 06:00:00AM +0300, Alexander Lakhin wrote:
>> BTW, there is a commitfest entry to eliminate a bunch of other stack
>> overflow hazards (may be the fuzzer can find some of them too):
>> https://commitfest.postgresql.org/43/4239/
> Thanks for the pointer, I'll double-check that. Some of the locations
> of stack depth checks proposed involve performance-sensitive code
> paths, though, like mcxt.c :/
I hadn't looked at the patch yet, but ... mcxt.c? How is that recursive?
Even if there is some path that recurses through that, wouldn't the
check be better placed in a less-hot part of the loop?
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-26 04:56 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 8+ messages in thread
From: Michael Paquier @ 2023-06-26 04:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alexander Lakhin <exclusion@gmail.com>; zuming.jiang@inf.ethz.ch; pgsql-bugs@lists.postgresql.org
On Mon, Jun 26, 2023 at 12:27:08AM -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Thanks for the pointer, I'll double-check that. Some of the locations
>> of stack depth checks proposed involve performance-sensitive code
>> paths, though, like mcxt.c :/
>
> I hadn't looked at the patch yet, but ... mcxt.c? How is that recursive?
> Even if there is some path that recurses through that, wouldn't the
> check be better placed in a less-hot part of the loop?
Yeah, that's my impression. I'll switch to the other thread after
looking more in details.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #17995: Segmentation fault caused by UPDATE statement
@ 2023-06-26 05:00 Alexander Lakhin <exclusion@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 8+ messages in thread
From: Alexander Lakhin @ 2023-06-26 05:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>; +Cc: zuming.jiang@inf.ethz.ch; pgsql-bugs@lists.postgresql.org; kyzevan23@mail.ru
26.06.2023 07:27, Tom Lane wrote:
> I hadn't looked at the patch yet, but ... mcxt.c? How is that recursive?
> Even if there is some path that recurses through that, wouldn't the
> check be better placed in a less-hot part of the loop?
In that thread Egor Chindyaskin showed proofs for stack overflow in all the
functions, that the fixes were proposed for. For example:
#MemoryContextStatsInternal
(n=1000000; printf "BEGIN;"; for ((i=1;i<=$n;i++)); do printf "SAVEPOINT s$i;"; done; printf "SELECT
pg_log_backend_memory_contexts(pg_backend_pid())") | psql >/dev/null
Though maybe for some of those functions less-hot places could be found to
check the stack.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2023-06-26 05:00 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-24 18:33 BUG #17995: Segmentation fault caused by UPDATE statement PG Bug reporting form <noreply@postgresql.org>
2023-06-24 19:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-06-24 20:48 ` Willian Colognesi <willian_colognesi@trimble.com>
2023-06-25 03:00 ` Alexander Lakhin <exclusion@gmail.com>
2023-06-26 04:21 ` Michael Paquier <michael@paquier.xyz>
2023-06-26 04:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-06-26 04:56 ` Michael Paquier <michael@paquier.xyz>
2023-06-26 05:00 ` Alexander Lakhin <exclusion@gmail.com>
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