Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
Date: 2024-03-06 16:00:00
Message-ID: 95461160-1214-4ac4-d65b-086182797b1d@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

04.03.2024 18:00, Alexander Lakhin wrote:
>
> 04.03.2024 00:39, Tom Lane wrote:
>>
>>> Seems like we need to do some more work at startup to enforce that
>>> we have the amount of stack we think we do, if we're on Linux.
>> After thinking about that some more, I'm really quite unenthused about
>> trying to remap the stack for ourselves.  It'd be both platform- and
>> architecture-dependent, and I'm afraid it'd introduce as many failure
>> modes as it removes.  (Notably, I'm not sure we could guarantee
>> there's a guard page below the stack.)  Since we've not seen reports
>> of this failure from the wild, I doubt it's worth the trouble.
>

I've discovered that the out-of-stack segfault can be reached without
hitting an ordinary OOM condition at all.

Please look at the demo script that finds -v value for the given sql
recursion (the predefined range works for a server built with
CPPFLAGS="-Og" ./configure --enable-cassert --enable-debug,
using gcc 11.3 on 64-bit Ubuntu):
for v in `seq 240000 100 260000`; do
echo "limit -v: $v"
ulimit -Sv $v
rm server.log

pg_ctl -l server.log start
dropdb test
createdb test

cat << 'EOF' | psql test >psql.log 2>&1
create function explainer(text) returns setof text
language plpgsql as
$$
declare
  ln text;
  begin
    for ln in execute format('explain analyze %s', $1)
    loop
      return next ln;
    end loop;
  end;
$$;

prepare stmt as select explainer('execute stmt');
select explainer('execute stmt');
EOF

pg_ctl stop || break
grep 'was terminated by signal 11' server.log && break;
done

This script fails for me as follows:
limit -v: 241100
waiting for server to start.... done
server started
waiting for server to shut down.......... done
server stopped
2024-03-06 14:45:26.882 UTC [38567] LOG:  server process (PID 38634) was terminated by signal 11: Segmentation fault
(with no out-of-memory errors in the server.log)

Core was generated by `postgres: law test [local] SELECT                                             '.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/38634' in core file too small.
#0  0x0000563ea8af7d60 in base_yyparse (yyscanner=yyscanner(at)entry=0x563eacbeec38) at gram.c:29020
bt
29020   {
(gdb) bt
#0  0x0000563ea8af7d60 in base_yyparse (yyscanner=yyscanner(at)entry=0x563eacbeec38) at gram.c:29020
#1  0x0000563ea8b37d4e in raw_parser (str=str(at)entry=0x563eacbf2c58 "explain analyze execute stmt", mode=<optimized out>)
at parser.c:77
#2  0x0000563ea8c19217 in _SPI_prepare_plan (src=src(at)entry=0x563eacbf2c58 "explain analyze execute stmt",
plan=plan(at)entry=0x7fffb16323b0) at spi.c:2235
#3  0x0000563ea8c1c5f5 in SPI_cursor_parse_open (name=name(at)entry=0x0, src=src(at)entry=0x563eacbf2c58 "explain analyze
execute stmt", options=options(at)entry=0x7fffb1632450) at spi.c:1554
...
#11389 0x0000563ea8d8bbf2 in exec_simple_query (query_string=query_string(at)entry=0x563eaa5c6328 "select
explainer('execute stmt');") at postgres.c:1273
#11390 0x0000563ea8d8daae in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4675
#11391 0x0000563ea8cf9c5d in BackendRun (port=port(at)entry=0x563eaa5f38c0) at postmaster.c:4475
#11392 0x0000563ea8cfcc10 in BackendStartup (port=port(at)entry=0x563eaa5f38c0) at postmaster.c:4151
#11393 0x0000563ea8cfcdae in ServerLoop () at postmaster.c:1769
#11394 0x0000563ea8cfe120 in PostmasterMain (argc=argc(at)entry=3, argv=argv(at)entry=0x563eaa5c1760) at postmaster.c:1468
#11395 0x0000563ea8c3148d in main (argc=3, argv=0x563eaa5c1760) at main.c:197

(gdb) i reg
rbp            0x563eacbeec38      0x563eacbeec38
rsp            0x7fffb16316b0      0x7fffb16316b0

(gdb) x/4 0x7fffb1631ff0
0x7fffb1631ff0: Cannot access memory at address 0x7fffb1631ff0
(gdb) x/4 0x7fffb1632000
0x7fffb1632000: 0       0       0       0

(gdb)  p stack_base_ptr
$1 = 0x7fffb17ac660 "\001"
(gdb) p stack_base_ptr - $rsp
$2 = 1552304

So it looks like a very specific corner stack-overflow case.

Best regards,
Alexander

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-03-06 17:28:11 Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build
Previous Message Laurenz Albe 2024-03-06 15:46:01 Re: BUG #18379: LDAP bind password exposed