Re: BUG #16036: Segmentation fault while doing an update

Hello,

Looks like disabling jit didn’t affect backtrace at all:

0  GetMemoryChunkContext (pointer=0x0) at ./build/../src/include/utils/memutils.h:127
#1  pfree (pointer=0x0) at ./build/../src/backend/utils/mmgr/mcxt.c:1033
#2  0x0000555d7276aaca in heap_freetuple (htup=<optimized out>) at
./build/../src/backend/access/common/heaptuple.c:1340
#3  0x0000555d72918889 in tts_buffer_heap_clear (slot=0x555d73dbb118) at
./build/../src/backend/executor/execTuples.c:652
#4  0x0000555d72918cbe in ExecClearTuple (slot=0x555d73dbb118) at ./build/../src/include/executor/tuptable.h:428
#5  ExecResetTupleTable (tupleTable=0x555d73db5a10, shouldFree=false) at
./build/../src/backend/executor/execTuples.c:1165
#6  0x0000555d7290ec40 in ExecEndPlan (estate=0x555d73db4aa0, planstate=<optimized out>) at
./build/../src/backend/executor/execMain.c:1560
#7  standard_ExecutorEnd (queryDesc=0x555d73ce1f40) at ./build/../src/backend/executor/execMain.c:496
#8  0x0000555d72a6d6e8 in ProcessQuery (plan=<optimized out>, sourceText=0x555d73ce1e20 "update tracking.test_session
setlist_position = list_position + 1 where id = $1", params=0x555d73ce1eb0, queryEnv=0x0, dest=0x555d73014c00
<donothingDR>,
    completionTag=0x7ffdf0913200 "UPDATE 0") at ./build/../src/backend/tcop/pquery.c:204
#9  0x0000555d72a6d8c3 in PortalRunMulti (portal=portal@entry=0x555d73c4d3f0, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false,dest=0x555d73014c00 <donothingDR>, dest@entry=0x555d73bafc90,
altdest=0x555d73014c00<donothingDR>, 
    altdest@entry=0x555d73bafc90, completionTag=completionTag@entry=0x7ffdf0913200 "UPDATE 0") at
./build/../src/backend/tcop/pquery.c:1283
#10 0x0000555d72a6e4db in PortalRun (portal=portal@entry=0x555d73c4d3f0, count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=true,run_once=<optimized out>, dest=dest@entry=0x555d73bafc90,
altdest=altdest@entry=0x555d73bafc90,
    completionTag=0x7ffdf0913200 "UPDATE 0") at ./build/../src/backend/tcop/pquery.c:796
#11 0x0000555d72a6bd05 in exec_execute_message (max_rows=9223372036854775807, portal_name=0x555d73baf880 "") at
./build/../src/backend/tcop/postgres.c:2090
#12 PostgresMain (argc=<optimized out>, argv=argv@entry=0x555d73bfb2e0, dbname=<optimized out>, username=<optimized
out>)at ./build/../src/backend/tcop/postgres.c:4297 
#13 0x0000555d7275fbe1 in BackendRun (port=0x555d73bf6be0, port=0x555d73bf6be0) at
./build/../src/backend/postmaster/postmaster.c:4431
#14 BackendStartup (port=0x555d73bf6be0) at ./build/../src/backend/postmaster/postmaster.c:4122
#15 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1704
#16 0x0000555d729f2e81 in PostmasterMain (argc=5, argv=0x555d73ba6b70) at
./build/../src/backend/postmaster/postmaster.c:1377
#17 0x0000555d72760ea8 in main (argc=5, argv=0x555d73ba6b70) at ./build/../src/backend/main/main.c:228

> 4 окт. 2019 г., в 4:09, Andres Freund <andres@anarazel.de> написал(а):
>
> Hi,
>
> On October 3, 2019 5:29:44 PM PDT, PG Bug reporting form <noreply@postgresql.org> wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference:      16036
>> Logged by:          Антон Власов
>> Email address:      druidvav@gmail.com
>> PostgreSQL version: 12.0
>> Operating system:   PostgreSQL 12.0 (Debian 12.0-1.pgdg90+1) on x86_64
>> Description:
>>
>> I am having segmentation fault like this:
>>
>> 2019-10-04 02:30:02 MSK [16919-6] LOG:  server process (PID 18415) was
>> terminated by signal 11: Segmentation fault
>> 2019-10-04 02:30:02 MSK [16919-7] DETAIL:  Failed process was running:
>> update tracking.test_session set list_position = list_position + 1
>> where id
>> = $1
>> 2019-10-04 02:30:02 MSK [16919-8] LOG:  terminating any other active
>> server
>> processes
>>
>> When there are several queries running simultaneously. Tried to get
>> some
>> info from coredump, but that's all i have:
>>
>> (gdb) bt
>> #0  GetMemoryChunkContext (pointer=0x0) at
>> ./build/../src/include/utils/memutils.h:127
>> #1  pfree (pointer=0x0) at
>> ./build/../src/backend/utils/mmgr/mcxt.c:1033
>> Backtrace stopped: Cannot access memory at address 0x7ffc990e7218
>
> Hm, can you reproduce this? If so, any chance to package this up in a reproducible manner?
>
> If not, could you check whether the problem vanishes if you set jit=off? If so, could you try getting a backtrace
aftersetting jit_debugging_support=1? 
>
>
> Regards,
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.