Обсуждение: BUG #17995: Segmentation fault caused by UPDATE statement
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.at --- 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
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
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
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
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
Вложения
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
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
Вложения
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