From: | Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Segmentation fault - PostgreSQL 17.0 |
Date: | 2024-11-11 14:22:03 |
Message-ID: | VI1PR02MB6333B652F5BD56FAD65DCC778A582@VI1PR02MB6333.eurprd02.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello.
> Could you maybe try on a completely new 17.0 cluster, not one that went
>through pg_upgrade? I don't think pg_upgrade should cause anything like
>this, but it'd be good to conclusively rule that out by reproducing the
>issue on a fresh cluster.
We can't reproduce the problem on a completely new 17.0 cluster.
Program received signal SIGSEGV, Segmentation fault.
0x00005627752205d5 in heap_compute_data_size (tupleDesc=tupleDesc(at)entry=0x5627a1e1eea0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:234
234 ./build/../src/backend/access/common/heaptuple.c: No such file or directory.
(gdb) print i
$1 = 6
(gdb) print numberOfAttributes
$2 = <optimized out>
(gdb) print *tupleDesc
$3 = {natts = 7, tdtypeid = 2249, tdtypmod = 0, tdrefcount = -1, constr = 0x0, attrs = 0x5627a1e1eeb8}
(gdb) print *atti
$4 = {attrelid = 0, attname = {data = "value", '\000' <repeats 58 times>}, atttypid = 25, attlen = -1, attnum = 7, attcacheoff = -1, atttypmod = -1, attndims = 0, attbyval = false,
attalign = 105 'i', attstorage = 120 'x', attcompression = 0 '\000', attnotnull = false, atthasdef = false, atthasmissing = false, attidentity = 0 '\000', attgenerated = 0 '\000',
attisdropped = false, attislocal = true, attinhcount = 0, attcollation = 100}
(gdb) print val
$5 = 0
(gdb) print values[0]
$6 = 1
(gdb) print values[1]
$7 = 0
(gdb) print values[2]
$8 = 1
(gdb) print values[3]
$9 = 0
(gdb) print values[4]
$10 = 0
(gdb) print values[5]
$11 = 0
(gdb) print values[6]
$12 = 0
(gdb) print values[7]
$13 = 94728219153600
(gdb) bt
#0 0x00005627752205d5 in heap_compute_data_size (tupleDesc=tupleDesc(at)entry=0x5627a1e1eea0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:234
#1 0x0000562775221e4f in heap_form_minimal_tuple (tupleDescriptor=0x5627a1e1eea0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:1492
#2 0x00005627756f0e45 in tuplestore_putvalues (state=0x5627a1e1f2a8, tdesc=<optimized out>, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/utils/sort/tuplestore.c:756
#3 0x00007fc7e2d0d9eb in brin_page_items (fcinfo=<optimized out>) at ./build/../contrib/pageinspect/brinfuncs.c:300
#4 0x00005627753d435c in ExecMakeTableFunctionResult (setexpr=0x5627a1e1ba40, econtext=0x5627a1e1b928, argContext=<optimized out>, expectedDesc=0x5627a1e1cbb0, randomAccess=false)
at ./build/../src/backend/executor/execSRF.c:234
#5 0x00005627753e527a in FunctionNext (node=node(at)entry=0x5627a1e1b720) at ./build/../src/backend/executor/nodeFunctionscan.c:93
#6 0x00005627753d4df9 in ExecScanFetch (recheckMtd=0x5627753e4f50 <FunctionRecheck>, accessMtd=0x5627753e4f80 <FunctionNext>, node=0x5627a1e1b720)
at ./build/../src/backend/executor/execScan.c:131
#7 ExecScan (node=0x5627a1e1b720, accessMtd=0x5627753e4f80 <FunctionNext>, recheckMtd=0x5627753e4f50 <FunctionRecheck>) at ./build/../src/backend/executor/execScan.c:180
#8 0x00005627753cb7bb in ExecProcNode (node=0x5627a1e1b720) at ./build/../src/include/executor/executor.h:274
#9 ExecutePlan (execute_once=<optimized out>, dest=0x5627a1c89478, direction=<optimized out>, numberTuples=200, sendTuples=<optimized out>, operation=CMD_SELECT,
use_parallel_mode=<optimized out>, planstate=0x5627a1e1b720, estate=0x5627a1e1b508) at ./build/../src/backend/executor/execMain.c:1648
#10 standard_ExecutorRun (queryDesc=0x5627a1da2d20, direction=<optimized out>, count=200, execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:365
#11 0x000056277557966e in PortalRunSelect (portal=0x5627a1d43188, forward=<optimized out>, count=200, dest=<optimized out>) at ./build/../src/backend/tcop/pquery.c:924
#12 0x000056277557a9b6 in PortalRun (portal=0x5627a1d43188, count=200, isTopLevel=<optimized out>, run_once=<optimized out>, dest=0x5627a1c89478, altdest=0x5627a1c89478, qc=0x7fff4744aa60)
at ./build/../src/backend/tcop/pquery.c:768
#13 0x000056277557817e in PostgresMain () at ./build/../src/backend/tcop/postgres.c:2255
#14 0x0000562775573423 in BackendMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ./build/../src/backend/tcop/backend_startup.c:105
#15 0x00005627754e366e in postmaster_child_launch (child_type=child_type(at)entry=B_BACKEND, startup_data=startup_data(at)entry=0x7fff4744ad70 "", startup_data_len=startup_data_len(at)entry=4,
client_sock=client_sock(at)entry=0x7fff4744ad90) at ./build/../src/backend/postmaster/launch_backend.c:277
#16 0x00005627754e7229 in BackendStartup (client_sock=0x7fff4744ad90) at ./build/../src/backend/postmaster/postmaster.c:3593
#17 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1674
#18 0x00005627754e8dbd in PostmasterMain (argc=<optimized out>, argv=0x5627a1c82f10) at ./build/../src/backend/postmaster/postmaster.c:1372
#19 0x0000562775212df0 in main (argc=5, argv=0x5627a1c82f10) at ./build/../src/backend/main/main.c:197
Ubuntu version:
[Mon Nov 11](09:58)# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
Extensions:
[cid:b86570c3-6fa1-4ba8-8fbd-ad92bdec55c5]
For Packages I attached a file apt-list-installed.txt.
Thank you.
Best regards, Lubo
________________________________
From: Tomas Vondra <tomas(at)vondra(dot)me>
Sent: Monday, 11 November 2024 14:48
To: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>; Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Segmentation fault - PostgreSQL 17.0
On 11/11/24 10:30, Ľuboslav Špilák wrote:
> Hello.
>
> After creating new database cluster (5433) in Postgresql 17 there was no
> problem with calling function
> select * from brin_page_items(
> get_raw_page(
>
>
> On the pg_upgraded cluster I got this backtrace on sigsegv. Is this
> helpful or do I need to include any more information?
>
Could you maybe try on a completely new 17.0 cluster, not one that went
through pg_upgrade? I don't think pg_upgrade should cause anything like
this, but it'd be good to conclusively rule that out by reproducing the
issue on a fresh cluster.
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00005627752205d5 in heap_compute_data_size
> (tupleDesc=tupleDesc(at)entry=0x5627a1df38c0,
> values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
> at ./build/../src/backend/access/common/heaptuple.c:234
> 234 ./build/../src/backend/access/common/heaptuple.c: No such file
> or directory.
> (gdb) bt
> #0 0x00005627752205d5 in heap_compute_data_size
> (tupleDesc=tupleDesc(at)entry=0x5627a1df38c0,
> values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
> at ./build/../src/backend/access/common/heaptuple.c:234
This is ... weird. heap_compute_data_size literally didn't change for
the last 9 years, so it's the same for 12 and 17. Line 234 is this:
Size
heap_compute_data_size(TupleDesc tupleDesc,
const Datum *values,
const bool *isnull)
{
Size data_length = 0;
int i;
int numberOfAttributes = tupleDesc->natts;
for (i = 0; i < numberOfAttributes; i++)
{
Datum val;
Form_pg_attribute atti;
if (isnull[i])
continue;
val = values[i];
atti = TupleDescAttr(tupleDesc, i);
if (ATT_IS_PACKABLE(atti) &&
VARATT_CAN_MAKE_SHORT(DatumGetPointer(val)))
I wonder which of the conditions triggers the segfault. Whether the one
accessing the attribute info (atti), or the one checking the pointer. It
has to be the first, because we're dealing with int8, and that's not a
varlena type, so it's not packable. So my guess would be atti is some
bogus pointer, with garbage.
Could you please print variables "i", "numberOfAttributes" and then also
the contents of tupleDesc and atti?
print i
print numberOfAttributes
print *tupleDesc
print *atti
regards
--
Tomas Vondra
________________________________
Textom tejto emailovej správy odosielateľ nesľubuje ani neuzatvára za spoločnosť MicroStep – HDO s.r.o. žiadnu zmluvu, nakoľko naša spoločnosť uzatvára každú zmluvu výlučne v písomnej forme. Ak Vám bol tento e-mail zaslaný omylom, prosím upozornite odosielateľa a tento e-mail odstráňte.
The sender of this e-mail message does not promise nor shall conclude any contract on the behalf of the company MicroStep HDO s.r.o. as our company enters into any contract exclusively in writing. If you have been sent this email in error, please notify the sender and delete this email.
Attachment | Content-Type | Size |
---|---|---|
apt-list-installed.txt | text/plain | 58.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-11-11 14:40:05 | Re: Segmentation fault - PostgreSQL 17.0 |
Previous Message | Tomas Vondra | 2024-11-11 13:59:06 | Re: Segmentation fault - PostgreSQL 17.0 |