Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

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@entry=0x55ceb9a4e090,
epqstate=epqstate@entry=0x55ceb9a4ed28,
relinfo=relinfo@entry=0x55ceb9a4e300,
    tupleid=tupleid@entry=0x7fff3cbcb92a,
fdw_trigtuple=fdw_trigtuple@entry=0x0,
newslot=newslot@entry=0x55ceba097a18) at trigger.c:3109
#7  0x000055ceb92ac464 in ExecUpdate
(mtstate=mtstate@entry=0x55ceb9a4ec30, tupleid=0x7fff3cbcb92a,
oldtuple=0x0, slot=0x55ceba097a18, planSlot=0x55ceba0978b8,
    epqstate=epqstate@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@entry=0x55ceb9a31750, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false,
    dest=0x55ceb977fb60 <donothingDR>, dest@entry=0x55ceb99cd950,
altdest=0x55ceb977fb60 <donothingDR>, altdest@entry=0x55ceb99cd950,
    completionTag=completionTag@entry=0x7fff3cbcbdd0 "") at pquery.c:1283
#14 0x000055ceb93d9e51 in PortalRun (portal=portal@entry=0x55ceb9a31750,
count=count@entry=1, isTopLevel=isTopLevel@entry=true,
run_once=run_once@entry=false,
    dest=dest@entry=0x55ceb99cd950,
altdest=altdest@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@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 <[email protected]> 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