Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From: Marcel Ruff <ruff(at)netwake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org, Adrian Batzill <Batzill(at)netwakevision(dot)com>
Subject: Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple
Date: 2019-11-10 15:55:14
Message-ID: a4639ece-13d5-c50a-b999-86bc787b3b78@netwake.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Hi,

I have compiled

   git clone git://git.postgresql.org/git/postgresql.git

to find out if this is more stable.

But /pg_ctl start/ says:

  /"The data directory was initialized by PostgreSQL version 12, which
is not compatible with this version 13devel"/

I can't follow this way, as it is a production system with several hours
of down time when doing pg_dump etc.

Marcel

Am 06.11.19 um 07:48 schrieb Marcel Ruff:
>
> Hi,
>
> here is the crash dump, it is the current postgresql 12 release (not
> yet a current git clone) on Debian Linux with 40G RAM and AMD Opteron
> 23xx (Gen 3 Class Opteron)
>
>     ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu --with-pam --with-openssl --with-libxml
> –with-libxslt –with-llvm --enable-debug
>     make -j 8
>     make install
>     cd contrib
>     make -j 8
>     make install
>
> and the default postgresql.conf but with jit = false (it also happens
> with jit = on):
>
> --------------
> [New LWP 21468]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `postgres: watchee watchee 127.'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at
> ../../../../src/include/utils/memutils.h:127
> 127             context = *(MemoryContext *) (((char *) pointer) -
> sizeof(void *));
> (gdb) where
> #0  0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at
> ../../../../src/include/utils/memutils.h:127
> #1  pfree (pointer=0x0) at mcxt.c:1033
> #2  0x000055ceb90fcfe5 in heap_freetuple (htup=<optimized out>) at
> heaptuple.c:1340
> #3  0x000055ceb92931a1 in tts_buffer_heap_clear (slot=0x55ceba097a18)
> at execTuples.c:652
> #4  0x000055ceb9293b05 in ExecClearTuple (slot=0x55ceba097a18) at
> ../../../src/include/executor/tuptable.h:428
> #5  ExecForceStoreHeapTuple (tuple=0x55ceb9aad760,
> slot=0x55ceba097a18, shouldFree=<optimized out>) at execTuples.c:1446
> #6  0x000055ceb926b851 in ExecBRUpdateTriggers
> (estate=estate(at)entry=0x55ceb9a4e090,
> epqstate=epqstate(at)entry=0x55ceb9a4ed28,
> relinfo=relinfo(at)entry=0x55ceb9a4e300,
>     tupleid=tupleid(at)entry=0x7fff3cbcb92a,
> fdw_trigtuple=fdw_trigtuple(at)entry=0x0,
> newslot=newslot(at)entry=0x55ceba097a18) at trigger.c:3109
> #7  0x000055ceb92ac464 in ExecUpdate
> (mtstate=mtstate(at)entry=0x55ceb9a4ec30, tupleid=0x7fff3cbcb92a,
> oldtuple=0x0, slot=0x55ceba097a18, planSlot=0x55ceba0978b8,
>     epqstate=epqstate(at)entry=0x55ceb9a4ed28, estate=0x55ceb9a4e090,
> canSetTag=true) at nodeModifyTable.c:1072
> #8  0x000055ceb92ad862 in ExecModifyTable (pstate=0x55ceb9a4ec30) at
> nodeModifyTable.c:2223
> #9  0x000055ceb928860b in ExecProcNode (node=0x55ceb9a4ec30) at
> ../../../src/include/executor/executor.h:239
> #10 ExecutePlan (execute_once=<optimized out>, dest=0x55ceb977fb60
> <donothingDR>, direction=<optimized out>, numberTuples=0,
> sendTuples=<optimized out>, operation=CMD_UPDATE,
>     use_parallel_mode=<optimized out>, planstate=0x55ceb9a4ec30,
> estate=0x55ceb9a4e090) at execMain.c:1646
> #11 standard_ExecutorRun (queryDesc=0x55ceba065378,
> direction=<optimized out>, count=0, execute_once=<optimized out>) at
> execMain.c:364
> #12 0x000055ceb93d9140 in ProcessQuery (plan=<optimized out>,
>     sourceText=0x55ceba065140 "update Location set enmea=$1, guid=$2,
> latDeci=$3, lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6,
> timestamp=$7, TRACK_ID=$8 where LOCATION_ID=$9",
> params=0x55ceba065268, queryEnv=0x0, dest=0x55ceb977fb60
> <donothingDR>, completionTag=0x7fff3cbcbdd0 "") at pquery.c:161
> #13 0x000055ceb93d9370 in PortalRunMulti
> (portal=portal(at)entry=0x55ceb9a31750, isTopLevel=isTopLevel(at)entry=true,
> setHoldSnapshot=setHoldSnapshot(at)entry=false,
>     dest=0x55ceb977fb60 <donothingDR>, dest(at)entry=0x55ceb99cd950,
> altdest=0x55ceb977fb60 <donothingDR>, altdest(at)entry=0x55ceb99cd950,
>     completionTag=completionTag(at)entry=0x7fff3cbcbdd0 "") at pquery.c:1283
> #14 0x000055ceb93d9e51 in PortalRun
> (portal=portal(at)entry=0x55ceb9a31750, count=count(at)entry=1,
> isTopLevel=isTopLevel(at)entry=true, run_once=run_once(at)entry=false,
>     dest=dest(at)entry=0x55ceb99cd950,
> altdest=altdest(at)entry=0x55ceb99cd950, completionTag=0x7fff3cbcbdd0 "")
> at pquery.c:796
> #15 0x000055ceb93d7557 in exec_execute_message (max_rows=1,
> portal_name=0x55ceb99cd540 "") at postgres.c:2090
> #16 PostgresMain (argc=<optimized out>,
> argv=argv(at)entry=0x55ceb99f5958, dbname=<optimized out>,
> username=<optimized out>) at postgres.c:4297
> --Type <RET> for more, q to quit, c to continue without paging--
> #17 0x000055ceb9363ce2 in BackendRun (port=0x55ceb99f1920,
> port=0x55ceb99f1920) at postmaster.c:4431
> #18 BackendStartup (port=0x55ceb99f1920) at postmaster.c:4122
> #19 ServerLoop () at postmaster.c:1704
> #20 0x000055ceb9364c10 in PostmasterMain (argc=1, argv=0x55ceb99c7270)
> at postmaster.c:1377
> #21 0x000055ceb90f3886 in main (argc=1, argv=0x55ceb99c7270) at main.c:228
>
> Thank you
> Marcel
>
> Am 04.11.19 um 15:24 schrieb Tom Lane:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>> On 2019-Nov-04, Marcel Ruff wrote:
>>>> Now I have upgraded to postgresql 12 and get a crash about once per day,
>>>> ...
>>>> How can I track down the problem?
>>> The first you need to do is obtain a crash dump. This page may help:
>>> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend
>> Also, as long as you're building from source anyway, you might pull down
>> v12 branch tip from our git repo, or use a nightly snapshot tarball [1]
>> to see if the problem's already fixed.
>>
>> regards, tom lane
>>
>> [1] https://www.postgresql.org/ftp/snapshot/12/
> --
> NetwakeVision
> Alte Owinger Straße 100
> D-88662 Überlingen
> Phone: +49 7551 309372
> http://www.netwakevision.com
> http://www.royal-gps.com
--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Lane 2019-11-10 15:59:16 Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple
Previous Message Marcel Ruff 2019-11-06 06:48:02 Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple