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 set list_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(at)entry=0x555d73c4d3f0, isTopLevel=isTopLevel(at)entry=true, setHoldSnapshot=setHoldSnapshot(at)entry=false, dest=0x555d73014c00 <donothingDR>, dest(at)entry=0x555d73bafc90, altdest=0x555d73014c00 <donothingDR>,
altdest(at)entry=0x555d73bafc90, completionTag=completionTag(at)entry=0x7ffdf0913200 "UPDATE 0") at ./build/../src/backend/tcop/pquery.c:1283
#10 0x0000555d72a6e4db in PortalRun (portal=portal(at)entry=0x555d73c4d3f0, count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true, run_once=<optimized out>, dest=dest(at)entry=0x555d73bafc90, altdest=altdest(at)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(at)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(at)anarazel(dot)de> написал(а):
>
> Hi,
>
> On October 3, 2019 5:29:44 PM PDT, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 16036
>> Logged by: Антон Власов
>> Email address: druidvav(at)gmail(dot)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 after setting jit_debugging_support=1?
>
>
> Regards,
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.