Thread: BUG #16283: crash on create index segmentation fault

BUG #16283: crash on create index segmentation fault

From
PG Bug reporting form
Date:
The following bug has been logged on the website:

Bug reference:      16283
Logged by:          Przemysław Szustak
Email address:      przemyslaw.szustak@gmail.com
PostgreSQL version: 10.12
Operating system:   Ubuntu 16.04.6 LTS
Description:

Postgresql crash segmentation fault on create index. 
More info https://github.com/przemyslaw-szustak/postgresql_postgis_crash.


Re: BUG #16283: crash on create index segmentation fault

From
Tomas Vondra
Date:
On Fri, Feb 28, 2020 at 02:23:21PM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference:      16283
>Logged by:          Przemysław Szustak
>Email address:      przemyslaw.szustak@gmail.com
>PostgreSQL version: 10.12
>Operating system:   Ubuntu 16.04.6 LTS
>Description:
>
>Postgresql crash segmentation fault on create index.
>More info https://github.com/przemyslaw-szustak/postgresql_postgis_crash.
>

This seems more like a bug in postgis, considering the last frame before
the segfault looks like this:

   #0  0x000055fb9015c45b in pfree ()
   #1  0x00007f64ee7f2b5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
   #2  0x00007f64ee7f4367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so
   #3  0x000055fb9013a272 in FunctionCall2Coll ()
   #4  0x000055fb8fd7f526 in gistSplitByKey ()

so it's a call from GiST, but the last two calls are somewhere in
PostGIS library. If I had to guess, I'd say this looks like double-free
or something like that.

Which PostGIS version are you using? Are you sure you have the latest
2.5.x version?

Also, maybe try to install packages with debug symbols, that should give
us a bit more context (parameters, line numbers, ...).

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: BUG #16283: crash on create index segmentation fault

From
Przemysław Szustak
Date:
I don't know why but now when I created this howto recreate crash I used new cluster (on these same server) and now system crash file is not created.
So now I have only info that postgres process has Segmentation fault.

I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).

So maybe I should report it to postgis bug tracking system?


pt., 28 lut 2020 o 17:26 Tomas Vondra <tomas.vondra@2ndquadrant.com> napisał(a):
On Fri, Feb 28, 2020 at 02:23:21PM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference:      16283
>Logged by:          Przemysław Szustak
>Email address:      przemyslaw.szustak@gmail.com
>PostgreSQL version: 10.12
>Operating system:   Ubuntu 16.04.6 LTS
>Description:
>
>Postgresql crash segmentation fault on create index.
>More info https://github.com/przemyslaw-szustak/postgresql_postgis_crash.
>

This seems more like a bug in postgis, considering the last frame before
the segfault looks like this:

   #0  0x000055fb9015c45b in pfree ()
   #1  0x00007f64ee7f2b5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
   #2  0x00007f64ee7f4367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so
   #3  0x000055fb9013a272 in FunctionCall2Coll ()
   #4  0x000055fb8fd7f526 in gistSplitByKey ()

so it's a call from GiST, but the last two calls are somewhere in
PostGIS library. If I had to guess, I'd say this looks like double-free
or something like that.

Which PostGIS version are you using? Are you sure you have the latest
2.5.x version?

Also, maybe try to install packages with debug symbols, that should give
us a bit more context (parameters, line numbers, ...).

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--


Z poważaniem,
Przemysław Szustak

Re: BUG #16283: crash on create index segmentation fault

From
Tomas Vondra
Date:
On Fri, Feb 28, 2020 at 06:43:40PM +0100, Przemysław Szustak wrote:
>I don't know why but now when I created this howto recreate crash I used
>new cluster (on these same server) and now system crash file is not created.
>So now I have only info that postgres process has Segmentation fault.
>

You probably need to tweak kernel.core_pattern - some systems have
custom scripts to process core files etc.

>I think that problem is in
>https://github.com/postgis/postgis/blob/master/postgis/gserialized_gist_nd.c#L1378.

><https://remote.lehmann-partner.pl/owa/redir.aspx?C=f49ce336d2324e4aa836bade6a95d11a&URL=https%3a%2f%2fgithub.com%2fpostgis%2fpostgis%2fblob%2fmaster%2fpostgis%2fgserialized_gist_nd.c%23L1378>
>I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699"
>[EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2,
>08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3"
>LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).
>

Yeah, that seems like the most recent version.

>So maybe I should report it to postgis bug tracking system?
>

Maybe, but I guess they'll ask you for the same information.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: BUG #16283: crash on create index segmentation fault

From
Przemysław Szustak
Date:
I updated info on github logs because now system was generated new core dump.

How can I get you more information? I don't now how to debug it.

pt., 28 lut 2020 o 19:11 Tomas Vondra <tomas.vondra@2ndquadrant.com> napisał(a):
On Fri, Feb 28, 2020 at 06:43:40PM +0100, Przemysław Szustak wrote:
>I don't know why but now when I created this howto recreate crash I used
>new cluster (on these same server) and now system crash file is not created.
>So now I have only info that postgres process has Segmentation fault.
>

You probably need to tweak kernel.core_pattern - some systems have
custom scripts to process core files etc.

>I think that problem is in
>https://github.com/postgis/postgis/blob/master/postgis/gserialized_gist_nd.c#L1378.
><https://remote.lehmann-partner.pl/owa/redir.aspx?C=f49ce336d2324e4aa836bade6a95d11a&URL=https%3a%2f%2fgithub.com%2fpostgis%2fpostgis%2fblob%2fmaster%2fpostgis%2fgserialized_gist_nd.c%23L1378>
>I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699"
>[EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2,
>08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3"
>LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).
>

Yeah, that seems like the most recent version.

>So maybe I should report it to postgis bug tracking system?
>

Maybe, but I guess they'll ask you for the same information.


regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--


Z poważaniem,
Przemysław Szustak

Re: BUG #16283: crash on create index segmentation fault

From
Tomas Vondra
Date:
On Fri, Feb 28, 2020 at 08:58:19PM +0100, Przemysław Szustak wrote:
>I updated info on github logs because now system was generated new core
>dump.
>
>How can I get you more information? I don't now how to debug it.
>

Well, it's hard to say what exactly is happening, without getting a
better backtrace. Your system is apparently missing debug symbols, so
you need to do something like

   sudo aptitude install postgresql-10-dbg

or something like that. And the same for postgis, I assume. Then
generate the backtrace again (using the existing core file).

You might also attach gdb to the running backend, trigger the issue
and do more investigation there.

1) determine the PID of the backend handling your connection

   db=# select pg_backend_pid();

2) attach GDB to the process

   $ gdb -p $PID
   (gdb) c

3) Run the query using the same backend, once it triggers you'll be able
to do 'bt' in the gdb shell and inspect variables.

This needs the debug symbols too, though.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: BUG #16283: crash on create index segmentation fault

From
Przemysław Szustak
Date:
I installed postgresql-10-dbg. I can't find how to do it in postgis.
sudo apt install postgis(tab tab)
    postgis      postgis-doc  postgis-gui
sudo apt install postgresql-10-postgis-(tab tab)
    postgresql-10-postgis-2.4          postgresql-10-postgis-2.4-scripts  postgresql-10-postgis-2.5          postgresql-10-postgis-2.5-scripts  postgresql-10-postgis-3            postgresql-10-postgis-3-scripts

I updated github info.
New logs from core dump was available below 'new crash dump file generated after install postgres dbg and run gbd -p 'postgres-10-PID''.
I generated bt from old dump crash too.




pt., 28 lut 2020 o 22:00 Tomas Vondra <tomas.vondra@2ndquadrant.com> napisał(a):
On Fri, Feb 28, 2020 at 08:58:19PM +0100, Przemysław Szustak wrote:
>I updated info on github logs because now system was generated new core
>dump.
>
>How can I get you more information? I don't now how to debug it.
>

Well, it's hard to say what exactly is happening, without getting a
better backtrace. Your system is apparently missing debug symbols, so
you need to do something like

   sudo aptitude install postgresql-10-dbg

or something like that. And the same for postgis, I assume. Then
generate the backtrace again (using the existing core file).

You might also attach gdb to the running backend, trigger the issue
and do more investigation there.

1) determine the PID of the backend handling your connection

   db=# select pg_backend_pid();

2) attach GDB to the process

   $ gdb -p $PID
   (gdb) c

3) Run the query using the same backend, once it triggers you'll be able
to do 'bt' in the gdb shell and inspect variables.

This needs the debug symbols too, though.


regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--


Z poważaniem,
Przemysław Szustak

Re: BUG #16283: crash on create index segmentation fault

From
Tomas Vondra
Date:
Hi,

On Mon, Mar 02, 2020 at 08:18:00PM +0100, Przemysław Szustak wrote:
>I installed postgresql-10-dbg. I can't find how to do it in postgis.
>sudo apt install postgis(tab tab)
>    postgis      postgis-doc  postgis-gui
>sudo apt install postgresql-10-postgis-(tab tab)
>    postgresql-10-postgis-2.4          postgresql-10-postgis-2.4-scripts
> postgresql-10-postgis-2.5          postgresql-10-postgis-2.5-scripts
> postgresql-10-postgis-3            postgresql-10-postgis-3-scripts
>

Not sure, but there should be postgis-dbgsym package, I think.

>I updated github info.

I find it rather annoying that we're discussing here but the relevant
debug info is somewhere on github, getting updated. That makes is almost
impossible for anyone to follow the discussion after a while. Please
copy the important bits here in the future (attach them as a file, if
necessary).

>New logs from core dump was available below '*new crash dump file generated
>after install postgres dbg and run gbd -p 'postgres-10-PID*''.
>I generated bt from old dump crash too.
>

Well, both crashes fail at the same place - the last three frames look
like this:

#0  pfree (pointer=0x7f7a6e4068f8) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
#1  0x00007f7a65e39b5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
#2  0x00007f7a65e3b367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so

which means it fails here:

   void
   pfree(void *pointer)
   {
     MemoryContext context = GetMemoryChunkContext(pointer);

     (*context->methods->free_p) (context, pointer);           <------
     VALGRIND_MEMPOOL_FREE(context, pointer);
   }

So the pointer passed to pfree() may be actually OK, but one of the
pointers (context, methods or free_p) is probably somehow borked. It's
hard to say from the backtrace, you'll have to inspect that from gdb
(see my previous message for basic instructions).

You'll probably need to install the postgis debug symbols first, but
maybe try without it.

Are you able to extract some subset of the data, so that people can
reproduce this locally?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: BUG #16283: crash on create index segmentation fault

From
Przemysław Szustak
Date:
OK, once again all info:


Used versions:
    Postgresql:
        psql -p 5432 -c "select version()" -d "test_crash"
        return:
        PostgreSQL 10.12 (Ubuntu 10.12-2.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609, 64-bit
    Postgis:
        psql -p 5432 -c "select postgis_full_version()" -d "test_crash"
        return:
        POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER
    System:
        lsb_release -a
            No LSB modules are available.
            Distributor ID:    Ubuntu
            Description:    Ubuntu 16.04.6 LTS
            Release:    16.04
            Codename:    xenial
        uname -a
            Linux 4.4.0-165-generic #193-Ubuntu SMP Tue Sep 17 17:42:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

How to restore crash:
    1. Create DB:
        psql -p 5432 -c "create database test_crash"
    2. Add postgis:
        psql -p 5432 -c "create extension postgis" -d "test_crash"
    3. Import data to DB (file "test_table.sql" in attachment):
        psql -p 5432 -f "./test_table.sql" -d "test_crash"
    4. Exec SQL:
        psql -p 5432 -c "drop index if exists test_table_geom_idx; CREATE INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection gist_geometry_ops_nd) TABLESPACE pg_default;" -d "test_crash"
    5. Program terminated with signal SIGSEGV, Segmentation fault.


How I generate crash and bt log (using your information and PostGIS tutorial https://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace).
    1. Login as postgres:
        sudo su; su postgres

    2. Open psql console:
        psql -p 5432 -d "test_crash".

    3. I try to check running pid:
        select postgis_full_version(), pg_backend_pid();
        return:
                                                                                                   postgis_full_version                                                                                                    | pg_backend_pid
        ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------
         POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER |          30691
        (1 row)

    4. In other console:
        sudo su;
        gdb -p 30691

    5. In first console (in psql) I run crash SQL:
        drop index if exists test_table_geom_idx; CREATE INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection gist_geometry_ops_nd) TABLESPACE pg_default;

    6. In secend console (gdb) I press c
        (gbd) c
        Continuing.

        Program received signal SIGSEGV, Segmentation fault.
        pfree (pointer=0x7f7a6ec008f8) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
        954    /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c: Nie ma takiego pliku ani katalogu.

        (gdb) bt
        #0  pfree (pointer=0x7f7a6ec008f8) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
        #1  0x00007f7a65c0eb5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
        #2  0x00007f7a65c10367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so
        #3  0x000055b80d1f6272 in FunctionCall2Coll (flinfo=flinfo@entry=0x55b80ef2dac8, collation=<optimized out>, arg1=arg1@entry=94249013099592, arg2=arg2@entry=140736435822256) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/fmgr/fmgr.c:1059
        #4  0x000055b80ce3b526 in gistUserPicksplit (len=227, giststate=0x55b80ef2bca8, itup=0x55b80ef21d18, v=0x7fffc1439eb0, attno=0, entryvec=0x55b80ef23c48, r=0x7f7a5705d668)
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistsplit.c:433
        #5  gistSplitByKey (r=r@entry=0x7f7a5705d668, page=page@entry=0x7f7a6ebfea00 "", itup=itup@entry=0x55b80ef21d18, len=len@entry=227, giststate=giststate@entry=0x55b80ef2bca8, v=v@entry=0x7fffc1439eb0, attno=0)
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistsplit.c:697
        #6  0x000055b80ce3252c in gistSplit (r=r@entry=0x7f7a5705d668, page=page@entry=0x7f7a6ebfea00 "", itup=0x55b80ef21d18, len=227, giststate=giststate@entry=0x55b80ef2bca8) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1375
        #7  0x000055b80ce32952 in gistplacetopage (rel=0x7f7a5705d668, freespace=<optimized out>, giststate=giststate@entry=0x55b80ef2bca8, buffer=1541, itup=itup@entry=0x7fffc143a388, ntup=ntup@entry=1, oldoffnum=0, newblkno=0x0, leftchildbuf=0, splitinfo=0x7fffc143a2c0,
            markfollowright=1 '\001', heapRel=0x7f7a5705c658) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:295
        #8  0x000055b80ce3341e in gistinserttuples (state=state@entry=0x7fffc143a390, stack=stack@entry=0x7fffc143a3b0, giststate=giststate@entry=0x55b80ef2bca8, tuples=tuples@entry=0x7fffc143a388, ntup=ntup@entry=1, oldoffnum=oldoffnum@entry=0, leftchild=0, rightchild=0,
            unlockbuf=0 '\000', unlockleftchild=0 '\000') at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1221
        #9  0x000055b80ce3382a in gistinserttuple (oldoffnum=0, tuple=0x55b80ef21ce8, giststate=0x55b80ef2bca8, stack=0x7fffc143a3b0, state=0x7fffc143a390) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1180
        #10 gistdoinsert (r=r@entry=0x7f7a5705d668, itup=itup@entry=0x55b80ef21ce8, freespace=<optimized out>, giststate=0x55b80ef2bca8, heapRel=<optimized out>) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:837
        #11 0x000055b80ce3cd11 in gistBuildCallback (index=index@entry=0x7f7a5705d668, htup=htup@entry=0x55b80eec6f80, values=values@entry=0x7fffc143a590, isnull=isnull@entry=0x7fffc143a8e0 "", tupleIsAlive=tupleIsAlive@entry=1 '\001', state=state@entry=0x7fffc143a9a0)
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistbuild.c:488
        #12 0x000055b80ceb15e7 in IndexBuildHeapRangeScan (heapRelation=heapRelation@entry=0x7f7a5705c658, indexRelation=indexRelation@entry=0x7f7a5705d668, indexInfo=indexInfo@entry=0x55b80eec6378, allow_sync=allow_sync@entry=1 '\001', anyvisible=anyvisible@entry=0 '\000',
            start_blockno=start_blockno@entry=0, numblocks=4294967295, callback=0x55b80ce3cc80 <gistBuildCallback>, callback_state=0x7fffc143a9a0) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2701
        #13 0x000055b80ceb1b0c in IndexBuildHeapScan (heapRelation=heapRelation@entry=0x7f7a5705c658, indexRelation=indexRelation@entry=0x7f7a5705d668, indexInfo=indexInfo@entry=0x55b80eec6378, allow_sync=allow_sync@entry=1 '\001',
            callback=callback@entry=0x55b80ce3cc80 <gistBuildCallback>, callback_state=callback_state@entry=0x7fffc143a9a0) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2271
        #14 0x000055b80ce3d380 in gistbuild (heap=0x7f7a5705c658, index=0x7f7a5705d668, indexInfo=0x55b80eec6378) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistbuild.c:207
        #15 0x000055b80ceb2923 in index_build (heapRelation=heapRelation@entry=0x7f7a5705c658, indexRelation=indexRelation@entry=0x7f7a5705d668, indexInfo=indexInfo@entry=0x55b80eec6378, isprimary=isprimary@entry=0 '\000', isreindex=isreindex@entry=0 '\000')
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2132
        #16 0x000055b80ceb42b9 in index_create (heapRelation=heapRelation@entry=0x7f7a5705c658, indexRelationName=indexRelationName@entry=0x55b80eec6738 "test_table_geom_idx", indexRelationId=599550, indexRelationId@entry=0, relFileNode=<optimized out>,
            indexInfo=indexInfo@entry=0x55b80eec6378, indexColNames=indexColNames@entry=0x55b80eec7388, accessMethodObjectId=783, tableSpaceId=1663, collationObjectId=0x55b80eec73d0, classObjectId=0x55b80eec73e8, coloptions=0x55b80eec7400, reloptions=0, isprimary=0 '\000',
            isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0 '\000', allow_system_table_mods=0 '\000', skip_build=0 '\000', concurrent=0 '\000', is_internal=0 '\000', if_not_exists=0 '\000')
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:1133
        #17 0x000055b80cf518b0 in DefineIndex (relationId=<optimized out>, relationId@entry=534024, stmt=stmt@entry=0x55b80eec6768, indexRelationId=indexRelationId@entry=0, is_alter_table=is_alter_table@entry=0 '\000', check_rights=check_rights@entry=1 '\001',
            check_not_in_use=check_not_in_use@entry=1 '\001', skip_build=0 '\000', quiet=0 '\000') at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/commands/indexcmds.c:682
        #18 0x000055b80d0e2f80 in ProcessUtilitySlow (pstate=pstate@entry=0x55b80eec6218, pstmt=pstmt@entry=0x55b80ee123c0,
            queryString=queryString@entry=0x55b80ee11358 "CREATE INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection gist_geometry_ops_nd) TABLESPACE pg_default;", context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=params@entry=0x0,
            queryEnv=queryEnv@entry=0x0, completionTag=0x7fffc143b3f0 "", dest=0x55b80ee124a0) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/utility.c:1336
        #19 0x000055b80d0e1f87 in standard_ProcessUtility (pstmt=0x55b80ee123c0, queryString=0x55b80ee11358 "CREATE INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection gist_geometry_ops_nd) TABLESPACE pg_default;", context=PROCESS_UTILITY_TOPLEVEL,
            params=0x0, queryEnv=0x0, dest=0x55b80ee124a0, completionTag=0x7fffc143b3f0 "") at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/utility.c:931
        #20 0x000055b80d0defab in PortalRunUtility (portal=0x55b80edab5a8, pstmt=0x55b80ee123c0, isTopLevel=<optimized out>, setHoldSnapshot=<optimized out>, dest=<optimized out>, completionTag=0x7fffc143b3f0 "")
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:1178
        #21 0x000055b80d0dfa98 in PortalRunMulti (portal=portal@entry=0x55b80edab5a8, isTopLevel=isTopLevel@entry=1 '\001', setHoldSnapshot=setHoldSnapshot@entry=0 '\000', dest=dest@entry=0x55b80ee124a0, altdest=altdest@entry=0x55b80ee124a0,
            completionTag=completionTag@entry=0x7fffc143b3f0 "") at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:1331
        #22 0x000055b80d0e0805 in PortalRun (portal=portal@entry=0x55b80edab5a8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x55b80ee124a0, altdest=altdest@entry=0x55b80ee124a0,
            completionTag=0x7fffc143b3f0 "") at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:799
        #23 0x000055b80d0dc2bc in exec_simple_query (query_string=0x55b80ee11358 "CREATE INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection gist_geometry_ops_nd) TABLESPACE pg_default;")
            at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/postgres.c:1122
        #24 0x000055b80d0dd7e8 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x55b80edb10c0, dbname=0x55b80edb0f88 "test_crash", username=<optimized out>) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/postgres.c:4128
        #25 0x000055b80ce1187e in BackendRun (port=0x55b80eda76a0) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:4408
        #26 BackendStartup (port=0x55b80eda76a0) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:4080
        #27 ServerLoop () at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:1756
        #28 0x000055b80d06b819 in PostmasterMain (argc=5, argv=<optimized out>) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:1364
        #29 0x000055b80ce12c75 in main (argc=5, argv=0x55b80ed5a850) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/main/main.c:228
        (gdb) c
        Continuing.

    7. When I press c in gdb secend time then in first psql I received:
        UWAGA:  indeks "test_table_geom_idx" nie istnieje, pominięto
        DROP INDEX
        server closed the connection unexpectedly
            This probably means the server terminated abnormally
            before or while processing the request.
        The connection to the server was lost. Attempting reset: Failed.

    8. When I try to continue or bt in gdb I received:
        Program terminated with signal SIGSEGV, Segmentation fault.
        The program no longer exists.
        (gdb) bt
        No stack.
        (gdb) c
        The program is not being run.
        (gdb)


Attachment

Re: BUG #16283: crash on create index segmentation fault

From
Arthur Cheysson
Date:
Hi everyone,

I am facing what seems to be the exact same problem, but with more 
recent versions of both PostgreSQL and PostGIS

SELECT version();
PostgreSQL 12.2 (Ubuntu 12.2-4) on x86_64-pc-linux-gnu, compiled by gcc 
(Ubuntu 9.3.0-8ubuntu1) 9.3.0, 64-bit

SELECT postgis_full_version();
POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="120" GEOS="3.8.0-CAPI-1.13.1 " 
PROJ="6.3.1" LIBXML="2.9.4" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" 
WAGYU="0.4.3 (Internal)"

I have been able to obtain a stacktrace with the PostGIS symbols, using 
`bt full' in GDB on the core dump.

#0  pfree (pointer=0x7fdd15acc1a8) at 
./build/../src/backend/utils/mmgr/mcxt.c:1035
         context = 0x4028000d051c0000
#1  0x00007fdd14c3a3c8 in gserialized_gist_picksplit_addlist 
(list=0x5639c5e19858, box_union=box_union@entry=0x5639c5e18f28, 
box_current=box_current@entry=0x7fdd15acc8e8, pos=pos@entry=0x5639c5e18ee8,
     num=num@entry=26) at gserialized_gist_nd.c:1378
No locals.
#2  0x00007fdd14c3ba23 in gserialized_gist_picksplit (fcinfo=<optimized 
out>) at gserialized_gist_nd.c:1722
         center = <optimized out>
         avgCenter = 0x5639c5e19c78
         entryvec = 0x5639c5e16cb8
         v = 0x7fff44b6f690
         i = <optimized out>
         box_union = 0x5639c5e18f08
         list = 0x5639c5e12be0
         pos = 0x5639c5e18ed8
         box_pageunion = 0x5639c5e10e00
         box_current = 0x7fdd15acc8e8
         direction = -1
         all_entries_equal = <optimized out>
         max_offset = 168
         nbytes = 340
         ndims_pageunion = 3
         d = <optimized out>
         posmin = 169
         __func__ = "gserialized_gist_picksplit"
#3  0x00005639c41fba99 in FunctionCall2Coll 
(flinfo=flinfo@entry=0x5639c5de3490, collation=<optimized out>, 
arg1=arg1@entry=94806133009592, arg2=arg2@entry=140734346229392)
     at ./build/../src/backend/utils/fmgr/fmgr.c:1162
         fcinfodata = {fcinfo = {flinfo = 0x5639c5de3490, context = 0x0, 
resultinfo = 0x0, fncollation = 100, isnull = false, nargs = 2, args = 
0x7fff44b6f4a0},
           fcinfo_data = "\220\064\336\305\071V", '\000' <repeats 18 
times>, 

"d\000\000\000\000V\002\000\270l\341\305\071V\000\000\000>\341\303\071V\000\000\220\366\266D\377\177\000\000\000\000\000\000\000\000\000"}
         fcinfo = 0x7fff44b6f480
         result = <optimized out>
         __func__ = "FunctionCall2Coll"
         __errno_location = <optimized out>
#4  0x00005639c3e1c4ab in gistUserPicksplit (len=168, 
giststate=0x5639c5de1668, itup=0x5639c5e10f20, v=0x7fff44b6f690, 
attno=0, entryvec=0x5639c5e16cb8, r=0x7fdd14d30ee8)
     at ./build/../src/backend/access/gist/gistsplit.c:433
         sv = 0x7fff44b6f690
         sv = <optimized out>
         __func__ = "gistUserPicksplit"
         __errno_location = <optimized out>
         NumDontCare = <optimized out>
         toMove = <optimized out>
#5  gistSplitByKey (r=r@entry=0x7fdd14d30ee8, 
page=page@entry=0x7fdd15acad00 "", itup=itup@entry=0x5639c5e10f20, 
len=168, giststate=giststate@entry=0x5639c5de1668, 
v=v@entry=0x7fff44b6f690, attno=0)
     at ./build/../src/backend/access/gist/gistsplit.c:697
         entryvec = 0x5639c5e16cb8
         offNullTuples = <optimized out>
         nOffNullTuples = <optimized out>
         i = <optimized out>
#6  0x00005639c3e1202b in gistSplit (r=0x7fdd14d30ee8, 
page=0x7fdd15acad00 "", itup=0x5639c5e10f20, len=<optimized out>, 
giststate=0x5639c5de1668) at ./build/../src/backend/access/gist/gist.c:1451
         lvectup = <optimized out>
         rvectup = <optimized out>
         v = {splitVector = {spl_left = 0x1, spl_nleft = 16384, 
spl_ldatum = 94806132985400, spl_ldatum_exists = false, spl_right = 
0x3fc5555555555515, spl_nright = -42257124, spl_rdatum = 0,
             spl_rdatum_exists = false}, spl_lattr = {94806132985400, 
140587513876200, 0, 3155123322044284928, 140734346229776, 
140734346229632, 94806132985264, 140734346229560, 140734346229552, 
140587513396116,
             4585845765077098099, 4607175408094817544, 
4604108167824115460, 4604952369619992743, 140734346229616, 
94806132985296, 140734346229696, 140734346230064, 140734346230432, 
140587513413085, 0,
             140587513122282, 4604103549945663722, 4583146448194962646, 
4604952369619992743, 140587513165489, 8, 94806132985256, 4, 
94806132985296, 8, 0}, spl_lisnull = {true, false <repeats 31 times>},
           spl_rattr = {0, 0, 0, 3155123322047568640, 140734346229856, 
94806132985296, 140734346230064, 140587523272732, 140734346230432, 
94806099337124, 94806132985296, 140587513413356, 140587513888440, 
140734346230030, 140734346231152, 140734346230064, 94802813124608, 0, 
140587513888652, 140734346230032, 94806132985392, 140587513888652, 
140587513888440, 140734346230064, 140734346230384, 94806099343697, 0, 
94806132984880, 1344, 844, 140734346230632, 140587528137984}, 
spl_risnull = {true, 249, 182, 68, 255, 127, false, false, 97, 225, 33, 
196, 57, 86, false, false, 48, 249, 182, 68, 255, 127, false, false, 
204, 249, 182, 68, 255, 127, false, false}, spl_dontcare = 0x1}
         i = <optimized out>
         res = 0x0
         __func__ = "gistSplit"
#7  0x00005639c3e123f3 in gistplacetopage (rel=0x7fdd14d30ee8, 
freespace=<optimized out>, giststate=giststate@entry=0x5639c5de1668, 
buffer=844, itup=itup@entry=0x7fff44b6fb68, ntup=ntup@entry=1, 
oldoffnum=0, newblkno=0x0, leftchildbuf=0, splitinfo=0x7fff44b6fab0, 
markfollowright=true, heapRel=0x7fdd14d2e118, is_build=true) at 
./build/../src/backend/access/gist/gist.c:299
         itvec = <optimized out>
         dist = 0x0
         oldnsn = 0
         npage = <optimized out>
         tlen = 168
         ptr = <optimized out>
         oldrlink = 4294967295
         rootpg = {block = {blkno = 350328448, num = 32733}, list = 
0x6066817f, lenlist = 1152842416, itup = 0x5639c40afe0a 
<ReadBuffer_common+1258>, page = 0x7fff44b6fae7 "", buffer = 0, next = 0x70}
         is_rootsplit = false
         blkno = 601
         page = 0x7fdd15acad00 ""
         is_leaf = true
         recptr = <optimized out>
         i = <optimized out>
         is_split = <optimized out>
         __func__ = "gistplacetopage"
#8  0x00005639c3e12f1e in gistinserttuples 
(state=state@entry=0x7fff44b6fba0, stack=stack@entry=0x5639c5e10ed0, 
giststate=giststate@entry=0x5639c5de1668, 
tuples=tuples@entry=0x7fff44b6fb68, ntup=ntup@entry=1, 
oldoffnum=oldoffnum@entry=0, leftchild=0, rightchild=0, unlockbuf=false, 
unlockleftchild=false) at ./build/../src/backend/access/gist/gist.c:1269
         splitinfo = 0x0
         is_split = <optimized out>
#9  0x00005639c3e1331e in gistinserttuple (oldoffnum=0, tuple=<optimized 
out>, giststate=0x5639c5de1668, stack=0x5639c5e10ed0, 
state=0x7fff44b6fba0) at ./build/../src/backend/access/gist/gist.c:1222
No locals.
#10 gistdoinsert (r=r@entry=0x7fdd14d30ee8, 
itup=itup@entry=0x5639c5e10e30, freespace=<optimized out>, 
giststate=0x5639c5de1668, heapRel=<optimized out>, 
is_build=is_build@entry=true) at 
./build/../src/backend/access/gist/gist.c:876
         iid = <optimized out>
         idxtuple = <optimized out>
         firststack = {blkno = 0, buffer = 211, page = 0x7fdd155d8d00 
"", lsn = 1, retry_from_parent = false, downlinkoffnum = 0, parent = 0x0}
         stack = 0x5639c5e10ed0
         state = {r = 0x7fdd14d30ee8, heapRel = 0x7fdd14d2e118, 
freespace = 819, is_build = true, stack = 0x5639c5e10ed0}
         xlocked = <optimized out>
         __func__ = "gistdoinsert"
#11 0x00005639c3e1dc91 in gistBuildCallback 
(index=index@entry=0x7fdd14d30ee8, htup=htup@entry=0x5639c5dd0a88,
values=values@entry=0x7fff44b6fd90, isnull=isnull@entry=0x7fff44b6fd70, 
tupleIsAlive=tupleIsAlive@entry=true, state=state@entry=0x7fff44b70170) 
at ./build/../src/backend/access/gist/gistbuild.c:489
         buildstate = 0x7fff44b70170
         itup = 0x5639c5e10e30
         oldCtx = 0x5639c5d3f820
#12 0x00005639c3e35e6c in heapam_index_build_range_scan 
(heapRelation=0x7fdd14d2e118, indexRelation=0x7fdd14d30ee8, 
indexInfo=0x5639c5d3feb8, allow_sync=<optimized out>, anyvisible=false, 
progress=true, start_blockno=0, numblocks=4294967295, 
callback=0x5639c3e1dc00 <gistBuildCallback>, 
callback_state=0x7fff44b70170, scan=0x5639c5dd0a38) at 
./build/../src/backend/access/heap/heapam_handler.c:1664
         tupleIsAlive = true
         hscan = 0x5639c5dd0a38
         is_system_catalog = false
         checking_uniqueness = false
         heapTuple = 0x5639c5dd0a88
         values = {140587523272732, 0, 94806132784048, 94806132804896, 
140587513896984, 140587720357032, 94806132765608, 140587712194344, 
140734346231536, 0, 140587720357008, 140734346231648, 94806105258868, 
94806105258868, 140734346231536, 140734346231292, 94806132765608, 
3086255563502438562, 18446744073709551472, 94806132784048, 
94806132804896, 3155123322047568640, 8744187018653911202, 128, 
94806105414899, 94806105414899, 140734346231552, 94806102306725, 
140734346231488, 0, 1, 16384}
         isnull = {false, 253, 182, 68, 255, 127, false, false, false, 
27, 50, 225, 241, 63, 201, 43, true, 64, false, false, 231, 4, false, 
false, 96, 255, 182, 68, 255, 127, false, false}
         reltuples = 66513
         predicate = 0x0
         slot = 0x5639c5d41488
         estate = 0x5639c5e12d70
         econtext = 0x5639c5e12f80
         snapshot = 0x5639c449e3e0 <SnapshotAnyData>
         need_unregister_snapshot = false
         OldestXmin = <optimized out>
         previous_blkno = 2590
         root_blkno = 2590
         root_offsets = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 
15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 0 <repeats 263 
times>}
         __func__ = "heapam_index_build_range_scan"
#13 0x00005639c3e1e2c5 in table_index_build_scan (scan=0x0, 
callback_state=0x7fff44b70170, callback=0x5639c3e1dc00 
<gistBuildCallback>, progress=true, allow_sync=true, 
index_info=0x5639c5d3feb8, index_rel=0x7fdd14d30ee8, 
table_rel=0x7fdd14d2e118) at ./build/../src/include/access/tableam.h:1522
No locals.
#14 gistbuild (heap=0x7fdd14d2e118, index=0x7fdd14d30ee8, 
indexInfo=0x5639c5d3feb8) at 
./build/../src/backend/access/gist/gistbuild.c:196
         result = <optimized out>
         reltuples = <optimized out>
         buildstate = {indexrel = 0x7fdd14d30ee8, heaprel = 
0x7fdd14d2e118, giststate = 0x5639c5de1668, indtuples = 66512, 
indtuplesSize = 2366816, freespace = 819, gfbb = 0x0, parentMap = 0x0, 
bufferingMode = GIST_BUFFERING_AUTO}
         buffer = 211
         page = <optimized out>
         oldcxt = 0x5639c5d3f820
         fillfactor = <optimized out>
         __func__ = "gistbuild"
#15 0x00005639c3e9be20 in index_build 
(heapRelation=heapRelation@entry=0x7fdd14d2e118, 
indexRelation=indexRelation@entry=0x7fdd14d30ee8, 
indexInfo=indexInfo@entry=0x5639c5d3feb8, 
isreindex=isreindex@entry=false, parallel=parallel@entry=true) at 
./build/../src/backend/catalog/index.c:2902
         stats = <optimized out>
         save_userid = 10
         save_sec_context = 0
         save_nestlevel = 2
         __func__ = "index_build"
#16 0x00005639c3e9d2a1 in index_create 
(heapRelation=heapRelation@entry=0x7fdd14d2e118, 
indexRelationName=indexRelationName@entry=0x5639c5d41698 
"people_person_coordinates_id", indexRelationId=<optimized out>, 
indexRelationId@entry=0, parentIndexRelid=parentIndexRelid@entry=0, 
parentConstraintId=parentConstraintId@entry=0, relFileNode=<optimized 
out>, indexInfo=<optimized out>, indexColNames=<optimized out>, 
accessMethodObjectId=<optimized out>, tableSpaceId=<optimized out>, 
collationObjectId=<optimized out>, classObjectId=<optimized out>, 
coloptions=<optimized out>, reloptions=<optimized out>, flags=<optimized 
out>, constr_flags=<optimized out>, allow_system_table_mods=<optimized 
out>, is_internal=<optimized out>, constraintId=<optimized out>) at 
./build/../src/backend/catalog/index.c:1221
         heapRelationId = <optimized out>
         pg_class = <optimized out>
         indexRelation = 0x7fdd14d30ee8
         indexTupDesc = 0x5639c5d417e8
         shared_relation = <optimized out>
         mapped_relation = <optimized out>
         is_exclusion = <optimized out>
         namespaceId = <optimized out>
         i = <optimized out>
         relpersistence = <optimized out>
         isprimary = <optimized out>
         invalid = <optimized out>
         concurrent = <optimized out>
         partitioned = <optimized out>
         relkind = <optimized out>
         relfrozenxid = 0
         relminmxid = 0
         __func__ = "index_create"
#17 0x00005639c3f36f2e in DefineIndex 
(relationId=relationId@entry=20147, stmt=stmt@entry=0x5639c5d3fba0, 
indexRelationId=indexRelationId@entry=0, 
parentIndexId=parentIndexId@entry=0, 
parentConstraintId=parentConstraintId@entry=0, 
is_alter_table=is_alter_table@entry=false, check_rights=true, 
check_not_in_use=true, skip_build=false, quiet=false) at 
./build/../src/backend/commands/indexcmds.c:1005
         concurrent = <optimized out>
         indexRelationName = 0x5639c5d41698 "people_person_coordinates_id"
         accessMethodName = <optimized out>
         typeObjectId = <optimized out>
         collationObjectId = <optimized out>
         classObjectId = <optimized out>
         accessMethodId = 783
         namespaceId = <optimized out>
         tablespaceId = 0
         createdConstraintId = 0
         indexColNames = 0x5639c5dd6928
         allIndexParams = <optimized out>
         rel = 0x7fdd14d2e118
         tuple = <optimized out>
         accessMethodForm = <optimized out>
         amRoutine = <optimized out>
         amcanorder = <optimized out>
         amoptions = <optimized out>
         partitioned = <optimized out>
         reloptions = 0
         coloptions = <optimized out>
         indexInfo = <optimized out>
         flags = <optimized out>
         constr_flags = <optimized out>
         numberOfAttributes = <optimized out>
         numberOfKeyAttributes = 1
         limitXmin = <optimized out>
         address = <optimized out>
         heaprelid = {relId = 3319621704, dbId = 22073}
         heaplocktag = <optimized out>
         lockmode = 5
         snapshot = <optimized out>
         save_nestlevel = -1
         i = <optimized out>
         __func__ = "DefineIndex"
#18 0x00005639c40e415f in ProcessUtilitySlow 
(pstate=pstate@entry=0x5639c5d3f930, pstmt=pstmt@entry=0x5639c5cf8f78, 
queryString=queryString@entry=0x5639c5cf7fd0 "CREATE INDEX 
people_person_coordinates_id ON public.people_person USING gist 
(coordinates);", context=context@entry=PROCESS_UTILITY_TOPLEVEL, 
params=params@entry=0x0, queryEnv=queryEnv@entry=0x0, 
completionTag=0x7fff44b70d60 "", dest=0x5639c5cf9058) at 
./build/../src/backend/tcop/utility.c:1372
         stmt = 0x5639c5d3fba0
         relid = 20147
         lockmode = <optimized out>
         save_exception_stack = 0x7fff44b70c20
         save_context_stack = 0x0
         local_sigjmp_buf = {{__jmpbuf = {140734346235232, 
8744187003067877538, 0, 94806131837944, 94806132128048, 94806131834832,
8744187003416004770, 3086257337499830434}, __mask_was_saved = 0, 
__saved_mask = {__val = {0, 0, 2, 2, 94802813127573, 4, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0}}}}
         parsetree = 0x5639c5cf8bf8
         isTopLevel = true
         isCompleteQuery = true
         needCleanup = false
         commandCollected = false
         address = {classId = 3, objectId = 0, objectSubId = 3}
         secondaryObject = {classId = 0, objectId = 0, objectSubId = 0}
         __func__ = "ProcessUtilitySlow"
#19 0x00005639c40e2c7f in standard_ProcessUtility (pstmt=0x5639c5cf8f78, 
queryString=0x5639c5cf7fd0 "CREATE INDEX people_person_coordinates_id ON 
public.people_person USING gist (coordinates);", 
context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, 
dest=0x5639c5cf9058, completionTag=0x7fff44b70d60 "") at 
./build/../src/backend/tcop/utility.c:927
         parsetree = 0x5639c5cf8bf8
         isTopLevel = <optimized out>
         isAtomicContext = false
         pstate = 0x5639c5d3f930
         __func__ = "standard_ProcessUtility"
#20 0x00005639c40dfcb4 in PortalRunUtility (portal=0x5639c5d809d0, 
pstmt=0x5639c5cf8f78, isTopLevel=<optimized out>, 
setHoldSnapshot=<optimized out>, dest=0x5639c5cf9058, 
completionTag=0x7fff44b70d60 "") at 
./build/../src/backend/tcop/pquery.c:1175
         utilityStmt = <optimized out>
         snapshot = 0x5639c5d9d340
#21 0x00005639c40e0767 in PortalRunMulti 
(portal=portal@entry=0x5639c5d809d0, isTopLevel=isTopLevel@entry=true, 
setHoldSnapshot=setHoldSnapshot@entry=false, 
dest=dest@entry=0x5639c5cf9058, altdest=altdest@entry=0x5639c5cf9058, 
completionTag=completionTag@entry=0x7fff44b70d60 "") at 
./build/../src/backend/tcop/pquery.c:1321
         pstmt = 0x5639c5cf8f78
         active_snapshot_set = false
         stmtlist_item = 0x5639c5cf9008
#22 0x00005639c40e13ae in PortalRun (portal=portal@entry=0x5639c5d809d0, 
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, 
run_once=run_once@entry=true, dest=dest@entry=0x5639c5cf9058, 
altdest=altdest@entry=0x5639c5cf9058, completionTag=0x7fff44b70d60 "") 
at ./build/../src/backend/tcop/pquery.c:796
         save_exception_stack = 0x7fff44b70f90
         save_context_stack = 0x0
         local_sigjmp_buf = {{__jmpbuf = {1, 8744187003107723426, 
94806132394448, 94806131838088, 2, 94806132394448, 8744187003021740194, 
3086257336272603298}, __mask_was_saved = 0, __saved_mask = {__val = {0, 
140736010536557, 94806105313453, 94806132406008, 94802813124609, 
94806132402800, 64, 94806131834560, 112, 94806131838088, 2, 
140734346235120, 94806103678836, 140734346235152, 2, 94806104811427}}}}
         result = <optimized out>
         nprocessed = <optimized out>
         saveTopTransactionResourceOwner = 0x5639c5d46578
         saveTopTransactionContext = 0x5639c5d9d200
         saveActivePortal = 0x0
         saveResourceOwner = 0x5639c5d46578
         savePortalContext = 0x0
         saveMemoryContext = 0x5639c5d9d200
         __func__ = "PortalRun"
#23 0x00005639c40dd257 in exec_simple_query (query_string=0x5639c5cf7fd0 
"CREATE INDEX people_person_coordinates_id ON public.people_person USING 
gist (coordinates);") at ./build/../src/backend/tcop/postgres.c:1215
         parsetree = 0x5639c5cf8c88
         portal = 0x5639c5d809d0
         snapshot_set = <optimized out>
         commandTag = <optimized out>
         completionTag = 

"\000\r\267D\377\177\000\000\000\000\000\000\000\000\000\000\240\r\267D\377\177\000\000\f\030\273D\377\177\000\000\344\220\302^\000\000\000\000\001\000\000\000\000\000\000\000\320\177\317\305\071V\000\000\060\017\267D\377\177\000"
         querytree_list = <optimized out>
         plantree_list = <optimized out>
         receiver = <optimized out>
         format = 0
         dest = DestRemote
         oldcontext = <optimized out>
         parsetree_list = 0x5639c5cf8cd8
         parsetree_item = 0x5639c5cf8cb8
         save_log_statement_stats = false
         was_logged = false
         use_implicit_block = false
         msec_str = 
"\000\r\267D\377\177\000\000\000\000\000\000\000\000\000\000\240\r\267D\377\177\000\000\f\030\273D\377\177\000"
         __func__ = "exec_simple_query"
#24 0x00005639c40deb6a in PostgresMain (argc=<optimized out>, 
argv=argv@entry=0x5639c5d44b08, dbname=<optimized out>, 
username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4247
         query_string = 0x5639c5cf7fd0 "CREATE INDEX 
people_person_coordinates_id ON public.people_person USING gist 
(coordinates);"
         firstchar = <optimized out>
         input_message = {data = 0x5639c5cf7fd0 "CREATE INDEX 
people_person_coordinates_id ON public.people_person USING gist 
(coordinates);", len = 92, maxlen = 1024, cursor = 92}
         local_sigjmp_buf = {{__jmpbuf = {1, 8744187002696681634, 
140734346235728, 1, 94806132148664, 0, 8744187003080460450, 
3086257350977570978}, __mask_was_saved = 1, __saved_mask = {__val = {0, 
140734346235952, 94806103782045, 140734346239683, 140734346239642, 
140734346239954, 0, 139637976727552, 3155123322047568640, 
94806131810240, 3155123322047568640, 140734346236176, 94806103782259, 
206158430256, 140734346236200, 140734346236000}}}}
         send_ready_for_query = false
         disable_idle_in_transaction_timeout = false
         __func__ = "PostgresMain"
#25 0x00005639c4069b6b in BackendRun (port=0x5639c5d40cd0, 
port=0x5639c5d40cd0) at ./build/../src/backend/postmaster/postmaster.c:4437
         av = 0x5639c5d44b08
         maxac = <optimized out>
         ac = 1
         i = 1
         av = <optimized out>
         maxac = <optimized out>
         ac = <optimized out>
         i = <optimized out>
         __func__ = "BackendRun"
         __errno_location = <optimized out>
         __errno_location = <optimized out>
         __errno_location = <optimized out>
#26 BackendStartup (port=0x5639c5d40cd0) at 
./build/../src/backend/postmaster/postmaster.c:4128
         bn = <optimized out>
         pid = <optimized out>
         bn = <optimized out>
         pid = <optimized out>
         __func__ = "BackendStartup"
         __errno_location = <optimized out>
         __errno_location = <optimized out>
         save_errno = <optimized out>
         __errno_location = <optimized out>
         __errno_location = <optimized out>
#27 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1704
         port = 0x5639c5d40cd0
         i = <optimized out>
         rmask = {fds_bits = {16, 0 <repeats 15 times>}}
         selres = <optimized out>
         now = <optimized out>
         readmask = {fds_bits = {24, 0 <repeats 15 times>}}
         nSockets = 5
         last_lockfile_recheck_time = 1589809339
         last_touch_time = 1589809279
         __func__ = "ServerLoop"
#28 0x00005639c406aa99 in PostmasterMain (argc=5, argv=<optimized out>) 
at ./build/../src/backend/postmaster/postmaster.c:1377
         opt = <optimized out>
         status = <optimized out>
         userDoption = <optimized out>
         listen_addr_saved = <optimized out>
         i = <optimized out>
         output_config_variable = <optimized out>
         __func__ = "PostmasterMain"
#29 0x00005639c3df1b88 in main (argc=5, argv=0x5639c5cf1ee0) at 
./build/../src/backend/main/main.c:228
         do_check_root = <optimized out>

I'm also trying to file a report with PostGIS (currently waiting for my 
UserID), but in the meantime, I'd be grateful if you had any ideas or
hints on where to go from here.

-- 
Arthur Cheysson
Developper for la France insoumise




Re: BUG #16283: crash on create index segmentation fault

From
Tom Lane
Date:
Arthur Cheysson <site@lafranceinsoumise.fr> writes:
> I am facing what seems to be the exact same problem, but with more 
> recent versions of both PostgreSQL and PostGIS

Given that stack trace, you need to be reporting this to the PostGIS
folk, not here.

They'll likely ask you for a reproducible test case, too ...

            regards, tom lane



Re: BUG #16283: crash on create index segmentation fault

From
Arthur Cheysson
Date:
I filed a bug with PostGIS, and I think I found the origin of the 
segfault in my case: this segfault seems to happen whenever there are a 
few empty points (with [nan, nan] as coordinates) in my column, in a 
non-deterministic manner.

https://trac.osgeo.org/postgis/attachment/ticket/4691/

Regards,
Arthur

Le 18/05/2020 à 18:22, Tom Lane a écrit :
> Arthur Cheysson <site@lafranceinsoumise.fr> writes:
>> I am facing what seems to be the exact same problem, but with more
>> recent versions of both PostgreSQL and PostGIS
> Given that stack trace, you need to be reporting this to the PostGIS
> folk, not here.
>
> They'll likely ask you for a reproducible test case, too ...
>
>             regards, tom lane