Обсуждение: points and boxes - core dump

I am facing an interesting core dump:

action=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 7.2 on i586-pc-linux-gnu, compiled by GCC 2.95.3
(1 row)


When computing the distance between a point and a box everything seems
to be ok:

action=# select '1,1'::point <-> '2,2,2,2'::box from t_struktur limit 3;

    ?column?
-----------------
 1.4142135623731
 1.4142135623731
 1.4142135623731
(3 rows)

Let's have a look at the data structure of the table:

action=# \d t_struktur
                                    Table "t_struktur"
 Column |           Type           |                       Modifiers
--------+--------------------------+-------------------------------------------------------

 tstamp | timestamp with time zone | default now()
 id     | bigint                   | not null default
nextval('"t_struktur_id_seq"'::text)
 koord  | box                      |
 typid  | bigint                   |
Indexes: idx_struktur_koord,
         idx_struktur_typid
Primary key: t_struktur_pkey
Rules: rule_struktur_del,
       rule_struktur_upd

When using the field koord instead of a static box the system will core
dump:

action=# select '1,1'::point <-> koord from t_struktur limit 3;
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.
!#

These are the first three records in the table:

action=# SELECT * FROM t_struktur LIMIT 3;
            tstamp             | id |    koord    | typid
-------------------------------+----+-------------+-------
 2002-05-08 14:30:17.594642+02 |  4 | (1,1),(1,1) |     4
 2002-05-07 12:28:07.113876+02 |  2 | (4,3),(2,1) |     4
 2002-05-08 14:36:15.152699+02 |  5 | (3,4),(1,2) |     3
(3 rows)

The strangen thing is that using the values directly seems to work
pretty well:

action=# SELECT '1,1'::point <-> '1,1,1,1'::box FROM t_struktur LIMIT 3;

 ?column?
----------
        0
        0
        0
(3 rows)

action=# SELECT '1,1'::point <-> '4,3,2,1'::box FROM t_struktur LIMIT 3;

 ?column?
----------
        1
        1
        1
(3 rows)

action=# SELECT '1,1'::point <-> '3,4,1,2'::box FROM t_struktur LIMIT 3;

 ?column?
----------
        1
        1
        1
(3 rows)

Does anybody have an idea why the problem occurs?

    Hans

Ewald Geschwinde <webmaster@geschwinde.net> writes:
> When using the field koord instead of a static box the system will core
> dump:

Hmm, I get garbage answers for the second and later rows, rather than
a core dump.

> Does anybody have an idea why the problem occurs?

I think the guilty party is the pfree() in dist_pb.  Given this set of
data close_pb will return its input Point pointer, so the net result is
dist_pb tries to pfree the supplied constant.  A bad move :-(.

I am strongly inclined to rip out *all* the pfrees of someone else's
result in geo_ops.c, not only that one.  Given the current handling of
memory management they are a waste of cycles and code space, and after
seeing this example I am not inclined to trust them not to be pfreeing
something they shouldn't.

            regards, tom lane

I said:
> I think the guilty party is the pfree() in dist_pb.

Indeed, removing the pfree call at line 2254 (in 7.2 sources) of
src/backend/utils/adt/geo_ops.c makes the problem go away.

I am working on a more extensive patch in hopes of fixing possible
similar errors elsewhere in this file, but that should get you going.

            regards, tom lane