Win32 GiST bug - more info

Hi guys,

Further to Paul Ramsey's email regarding problems with GiST under Win32,
I've been able to get some more information using gdb under MingW.

It looks as if something strange is going on with one of the pointers
being used during the creation of the GiST index. Here is the output
from gdb which shows that the problem occurs in the gbox_union()
function when trying to build a GiST index using the PostGIS spatial
extensions to PostgreSQL:

$ gdb ./postgres.exe
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) attach 3984
Attaching to program `c:\pgsql75win\bin/./postgres.exe', process 3984
[Switching to thread 3984.0xdbc]
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3984.0x1a8]
0x6d850a9a in gbox_union (fcinfo=0x22d470) at postgis_gist_72.c:342
342 if (pageunion->high.x < cur->high.x)
(gdb) bt
#0 0x6d850a9a in gbox_union (fcinfo=0x22d470) at postgis_gist_72.c:342
#1 0x00000000 in ?? ()
(gdb) print pageunion
$1 = (BOX *) 0x141b6b0
(gdb) print cur
$2 = (BOX *) 0x7f7f7f7e
(gdb) print entryvec
$3 = (bytea *) 0x1453e24
(gdb) print sizep
$4 = (int *) 0x22d55c

The actual function itself looks like this:

Datum gbox_union(PG_FUNCTION_ARGS)
{
bytea *entryvec = (bytea *) PG_GETARG_POINTER(0);
int *sizep = (int *) PG_GETARG_POINTER(1);
int numranges,
i;
BOX *cur,
*pageunion;

#ifdef DEBUG_GIST
elog(NOTICE,"GIST: gbox_union called\n");
fflush( stdout );
#endif

numranges = (VARSIZE(entryvec) - VARHDRSZ) / sizeof(GISTENTRY);
pageunion = (BOX *) palloc(sizeof(BOX));
cur = DatumGetBoxP(((GISTENTRY *) VARDATA(entryvec))[0].key);
memcpy((void *) pageunion, (void *) cur, sizeof(BOX));

for (i = 1; i < numranges; i++)
{
cur = DatumGetBoxP(((GISTENTRY *)
VARDATA(entryvec))[i].key);
if (pageunion->high.x < cur->high.x)
pageunion->high.x = cur->high.x;
if (pageunion->low.x > cur->low.x)
pageunion->low.x = cur->low.x;
if (pageunion->high.y < cur->high.y)
pageunion->high.y = cur->high.y;
if (pageunion->low.y > cur->low.y)
pageunion->low.y = cur->low.y;
}
*sizep = sizeof(BOX);

PG_RETURN_POINTER(pageunion);
}

Looking at the pointers, the value for cur looks quite suspicious ;)
Could it be some sort of alignment/pointer problem with the GISTENTRY or
VAR* macros? I can provide as much information as required if someone
can talk me through what I need to do using gdb. The version of
PostgreSQL being used was taken from CVS last Friday (21/05/2004).

Many thanks,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.