[postgis-tickets] [PostGIS] #4990: getfacecontainingpoint fails on i386

[PostGIS]

#4990: getfacecontainingpoint fails on i386
-----------------------------+---------------------------
  Reporter:  Bas Couwenberg  |      Owner:  strk
      Type:  defect          |     Status:  new
  Priority:  medium          |  Milestone:  PostGIS 3.2.0
 Component:  topology        |    Version:  master
Resolution:                  |   Keywords:
-----------------------------+---------------------------

Comment (by strk):

 The failing test is t9, that is:
 {{{
 select getfacecontainingpoint('city_data', 'POINT(7.1 31)');
 }}}

 Here's the run with debugging on:
 {{{
 DEBUG:  [lwgeom_topo.c:lwt_GetFaceContainingPoint:7097] Shortest line to
 closest edge 26: (null)
 DEBUG:  [lwgeom_topo.c:lwt_GetFaceContainingPoint:7103] Closest point on
 closest edge: POINT(7 31)
 DEBUG:  [lwgeom_topo.c:lwt_GetFaceContainingPoint:7209] Closest point is
 NOT a node
 DEBUG:  [lwgeom_topo.c:lwt_GetFaceContainingPoint:7236] Closest segment to
 edge 26 is 0
 DEBUG:  [lwgeom_topo.c:lwt_GetFaceContainingPoint:7239] Closest segment to
 edge 26 is LINESTRING(0 5.31406e-315, 5.32539e-315 5.31406e-315)
 ERROR:  Closest point is first point of closest segment, unexpectedly
 }}}

 The "closest segment" is clearly bogus, and it's probably because of the
 unaligned memory.
 I'm on the right track to fix that, but keep thinking we could be nice and
 ALWAYS align the pointarray memory to the double boundary

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4990#comment:20>
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.