[postgis-tickets] [PostGIS] #4174: segfault when using spgist

[PostGIS]

#4174: segfault when using spgist
----------------------+---------------------------
  Reporter:  TobWen   |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 2.5.0
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:
----------------------+---------------------------

Comment (by TobWen):

 **RhodiumToad** on #postgresql analyzed this. ''It might be a problem in
 core''!

 {{{
 <RhodiumToad> I think this can only be triggered by a LATERAL subquery
 with a LIMIT that does an spgist index scan using an opclass that stores
 traversal values
 <RhodiumToad> which I don't think the builtin opclasses do, but postgis
 does
 <FunkyBob> RhodiumToad: so... it's moderately obscure to trigger?
 <RhodiumToad> spgrescan starts out by doing
 MemoryContextReset(so->traversalCxt);
 <RhodiumToad> but then later calls resetSpGistScanOpaque(so);
 <RhodiumToad> and that calls freeScanStack
 <RhodiumToad> and that calls freeScanStackEntry
 <RhodiumToad> and that does  if (stackEntry->traversalValue)
 pfree(stackEntry->traversalValue);
 <RhodiumToad> but stackEntry->traversalValue is supposed to be allocated
 inside so->traversalCxt
 <RhodiumToad> so it can only break if you do a rescan while there's
 already a scan in progress that has entries stacked
 <RhodiumToad> so it may not just be that it's a lateral (... limit) query,
 it may also depend on the particular point at which the limit is hit
 RhodiumToad> I'm going to post about this to hackers
 }}}

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4174#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.