Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: BUG #16036: Segmentation fault while doing an update
From: =?utf-8?B?0JDQvdGC0L7QvSDQktC70LDRgdC+0LI=?= <druidvav@gmail.com>
In-Reply-To: <4E1FB33C-7280-487B-B3D1-D3C247AA9E3D@anarazel.de>
Date: Fri, 4 Oct 2019 04:14:33 +0300
Cc: pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBA5344D-9356-49BA-9B47-C3705C2E9481@gmail.com>
References: <16036-28184c90d952fb7f@postgresql.org>
 <4E1FB33C-7280-487B-B3D1-D3C247AA9E3D@anarazel.de>
To: Andres Freund <andres@anarazel.de>
Precedence: bulk

Hello,

Looks like disabling jit didn=E2=80=99t affect backtrace at all:

0  GetMemoryChunkContext (pointer=3D0x0) at =
./build/../src/include/utils/memutils.h:127
#1  pfree (pointer=3D0x0) at =
./build/../src/backend/utils/mmgr/mcxt.c:1033
#2  0x0000555d7276aaca in heap_freetuple (htup=3D<optimized out>) at =
./build/../src/backend/access/common/heaptuple.c:1340
#3  0x0000555d72918889 in tts_buffer_heap_clear (slot=3D0x555d73dbb118) =
at ./build/../src/backend/executor/execTuples.c:652
#4  0x0000555d72918cbe in ExecClearTuple (slot=3D0x555d73dbb118) at =
./build/../src/include/executor/tuptable.h:428
#5  ExecResetTupleTable (tupleTable=3D0x555d73db5a10, shouldFree=3Dfalse) =
at ./build/../src/backend/executor/execTuples.c:1165
#6  0x0000555d7290ec40 in ExecEndPlan (estate=3D0x555d73db4aa0, =
planstate=3D<optimized out>) at =
./build/../src/backend/executor/execMain.c:1560
#7  standard_ExecutorEnd (queryDesc=3D0x555d73ce1f40) at =
./build/../src/backend/executor/execMain.c:496
#8  0x0000555d72a6d6e8 in ProcessQuery (plan=3D<optimized out>, =
sourceText=3D0x555d73ce1e20 "update tracking.test_session set =
list_position =3D list_position + 1 where id =3D $1", =
params=3D0x555d73ce1eb0, queryEnv=3D0x0, dest=3D0x555d73014c00 =
<donothingDR>,
    completionTag=3D0x7ffdf0913200 "UPDATE 0") at =
./build/../src/backend/tcop/pquery.c:204
#9  0x0000555d72a6d8c3 in PortalRunMulti =
(portal=3Dportal@entry=3D0x555d73c4d3f0, =
isTopLevel=3DisTopLevel@entry=3Dtrue, =
setHoldSnapshot=3DsetHoldSnapshot@entry=3Dfalse, dest=3D0x555d73014c00 =
<donothingDR>, dest@entry=3D0x555d73bafc90, altdest=3D0x555d73014c00 =
<donothingDR>,
    altdest@entry=3D0x555d73bafc90, =
completionTag=3DcompletionTag@entry=3D0x7ffdf0913200 "UPDATE 0") at =
./build/../src/backend/tcop/pquery.c:1283
#10 0x0000555d72a6e4db in PortalRun (portal=3Dportal@entry=3D0x555d73c4d3f=
0, count=3Dcount@entry=3D9223372036854775807, =
isTopLevel=3DisTopLevel@entry=3Dtrue, run_once=3D<optimized out>, =
dest=3Ddest@entry=3D0x555d73bafc90, =
altdest=3Daltdest@entry=3D0x555d73bafc90,
    completionTag=3D0x7ffdf0913200 "UPDATE 0") at =
./build/../src/backend/tcop/pquery.c:796
#11 0x0000555d72a6bd05 in exec_execute_message =
(max_rows=3D9223372036854775807, portal_name=3D0x555d73baf880 "") at =
./build/../src/backend/tcop/postgres.c:2090
#12 PostgresMain (argc=3D<optimized out>, =
argv=3Dargv@entry=3D0x555d73bfb2e0, dbname=3D<optimized out>, =
username=3D<optimized out>) at =
./build/../src/backend/tcop/postgres.c:4297
#13 0x0000555d7275fbe1 in BackendRun (port=3D0x555d73bf6be0, =
port=3D0x555d73bf6be0) at =
./build/../src/backend/postmaster/postmaster.c:4431
#14 BackendStartup (port=3D0x555d73bf6be0) at =
./build/../src/backend/postmaster/postmaster.c:4122
#15 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1704
#16 0x0000555d729f2e81 in PostmasterMain (argc=3D5, argv=3D0x555d73ba6b70)=
 at ./build/../src/backend/postmaster/postmaster.c:1377
#17 0x0000555d72760ea8 in main (argc=3D5, argv=3D0x555d73ba6b70) at =
./build/../src/backend/main/main.c:228

> 4 =D0=BE=D0=BA=D1=82. 2019 =D0=B3., =D0=B2 4:09, Andres Freund =
<andres@anarazel.de> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
> Hi,=20
>=20
> 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:
>>=20
>> Bug reference:      16036
>> Logged by:          =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=92=D0=BB=D0=B0=D1=
=81=D0=BE=D0=B2
>> Email address:      druidvav@gmail.com
>> PostgreSQL version: 12.0
>> Operating system:   PostgreSQL 12.0 (Debian 12.0-1.pgdg90+1) on =
x86_64
>> Description:       =20
>>=20
>> I am having segmentation fault like this:
>>=20
>> 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 =3D list_position + 1
>> where id
>> =3D $1
>> 2019-10-04 02:30:02 MSK [16919-8] LOG:  terminating any other active
>> server
>> processes
>>=20
>> When there are several queries running simultaneously. Tried to get
>> some
>> info from coredump, but that's all i have:
>>=20
>> (gdb) bt
>> #0  GetMemoryChunkContext (pointer=3D0x0) at
>> ./build/../src/include/utils/memutils.h:127
>> #1  pfree (pointer=3D0x0) at
>> ./build/../src/backend/utils/mmgr/mcxt.c:1033
>> Backtrace stopped: Cannot access memory at address 0x7ffc990e7218
>=20
> Hm, can you reproduce this? If so, any chance to package this up in a =
reproducible manner?
>=20
> If not, could you check whether the problem vanishes if you set =
jit=3Doff? If so, could you try getting a backtrace after setting =
jit_debugging_support=3D1?
>=20
>=20
> Regards,
>=20
> Andres
> --=20
> Sent from my Android device with K-9 Mail. Please excuse my brevity.