Message-ID: <485cf2a2-d504-fb5f-6751-1085ccf614ec@mail.ru>
Date: Fri, 20 Jan 2023 12:50:20 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Stack overflow issue
Content-Language: en-US
To: Sascha Kuhl <yogidabanli@gmail.com>
References: <1661334672.728714027@f473.i.mail.ru>
 <CAPvVvKCHJ_QthWsYM3SDc6Xr3PBTcOq0EOgD+y7dwbtFCz2buw@mail.gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
From: Egor Chindyaskin <kyzevan23@mail.ru>
In-Reply-To: <CAPvVvKCHJ_QthWsYM3SDc6Xr3PBTcOq0EOgD+y7dwbtFCz2buw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/485cf2a2-d504-fb5f-6751-1085ccf614ec%40mail.ru>
Precedence: bulk


03.01.2023 22:45, Sascha Kuhl writes:
> Great work. Max Stack depth is memory dependent? Processor dependent?
Hello! These situations are not specific to the x86_64 architecture, but 
also manifest themselves, for example, on aarch64 architecture.
For example this query, ran on aarch64, (n=1000000;printf "begin;"; for 
((i=1;i<=$n;i++)); do printf "savepoint s$i;"; done; printf "release 
s1;" ) | psql > /dev/null
crashed the server on the savepoint174617 with the following stacktrace:

Core was generated by `postgres: test test [local] 
SAVEPOINT                     '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  AllocSetCheck (context=<error reading variable: Cannot access memory 
at address 0xffffe2397fe8>) at aset.c:1409
1409    {
(gdb) bt
#0  AllocSetCheck (context=<error reading variable: Cannot access memory 
at address 0xffffe2397fe8>) at aset.c:1409
#1  0x0000aaaad78c38c4 in MemoryContextCheck (context=0xaaab39ee16a0) at 
mcxt.c:740
#2  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39edf690) at 
mcxt.c:742
#3  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39edd680) at 
mcxt.c:742
#4  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39edb670) at 
mcxt.c:742
#5  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ed9660) at 
mcxt.c:742
#6  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ed7650) at 
mcxt.c:742
#7  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ed5640) at 
mcxt.c:742
#8  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ed3630) at 
mcxt.c:742
#9  0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ed1620) at 
mcxt.c:742
#10 0x0000aaaad78c38dc in MemoryContextCheck (context=0xaaab39ecf610) at 
mcxt.c:742
...
#174617 0x0000aaaad78c38dc in MemoryContextCheck 
(context=0xaaaae47994b0) at mcxt.c:742
#174618 0x0000aaaad78c38dc in MemoryContextCheck 
(context=0xaaaae476dcd0) at mcxt.c:742
#174619 0x0000aaaad78c38dc in MemoryContextCheck 
(context=0xaaaae46ead50) at mcxt.c:742
#174620 0x0000aaaad76c7e24 in finish_xact_command () at postgres.c:2739
#174621 0x0000aaaad76c55b8 in exec_simple_query 
(query_string=0xaaaae46f0540 "savepoint s174617;") at postgres.c:1238
#174622 0x0000aaaad76ca7a4 in PostgresMain (argc=1, argv=0xffffe2b96898, 
dbname=0xaaaae471c098 "test", username=0xaaaae471c078 "test") at 
postgres.c:4508
#174623 0x0000aaaad75e263c in BackendRun (port=0xaaaae4711470) at 
postmaster.c:4530
#174624 0x0000aaaad75e1f70 in BackendStartup (port=0xaaaae4711470) at 
postmaster.c:4252
#174625 0x0000aaaad75dd4c0 in ServerLoop () at postmaster.c:1745
#174626 0x0000aaaad75dcd3c in PostmasterMain (argc=3, 
argv=0xaaaae46eacb0) at postmaster.c:1417
#174627 0x0000aaaad74d462c in main (argc=3, argv=0xaaaae46eacb0) at 
main.c:209