[postgis-devel] C-Library function returning PostGIS point crashing backend
David Fuhry
dfuhry at gmail.com
Thu Jan 10 11:29:31 PST 2013
Paul and strk, thanks for the suggestions. strk: My source tree is behind
HEAD and lwgeom_set_handlers does not appear in it; I'll look out for that
in the future.
I built the latest stable versions of PostgreSQL (9.2.2) and PostGIS
(2.0.2), both built with --enable-debug, on a different machine (RHEL 6)
and following Paul's instructions, got the following backtrace showing the
segfault occurring in pfree:
$ PGDATA=/mnt/drive2/postgres/main gdb postgres
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/pgsql/bin/postgres...done.
(gdb) run --single dfuhry
Starting program: /usr/local/pgsql/bin/postgres --single dfuhry
PostgreSQL stand-alone backend 9.2.2
backend> select test2();
[g_serialized.c:gserialized_from_any_size:378] Input type: Point
[g_serialized.c:gserialized_from_lwpoint_size:286] point size = 24
[g_serialized.c:gserialized_from_lwgeom_size:420] g_serialize size = 32
[g_serialized.c:gserialized_from_lwgeom_any:677] Input type (1) Point,
hasz: 0 hasm: 0
[g_serialized.c:gserialized_from_lwgeom_any:678] LWGEOM(0xc5a200)
uint8_t(0xc5a238)
[g_serialized.c:gserialized_from_lwpoint:445]
lwpoint_to_gserialized(0xc5a200, 0xc5a238) called
[g_serialized.c:gserialized_set_srid:78] Called with srid = 4326
1: test2 (typeid = 16391, len = -1, typmod = -1, byval = f)
----
[g_serialized.c:gserialized_get_type:50] entered
[g_serialized.c:lwgeom_from_gserialized:1137] Got type 1 (Point), srid=4326
[g_serialized.c:lwgeom_from_gserialized_buffer:1091] Got type 1 (Point),
hasz=0 hasm=0 geodetic=0 hasbox=0
[g_serialized.c:gserialized_get_type:50] entered
[lwgeom.c:lwgeom_set_srid:1360] entered with srid=4326
[lwgeom.c:lwgeom_is_empty:1138] lwgeom_is_empty: got type Point
[lwout_wkb.c:lwgeom_to_wkb:702] WKB output size: 25
[lwout_wkb.c:lwgeom_to_wkb:715] Hex WKB output size: 51
[lwgeom.c:lwgeom_is_empty:1138] lwgeom_is_empty: got type Point
[lwout_wkb.c:lwpoint_to_wkb_buf:385] Entering function, buf = 0xc63e40
[lwout_wkb.c:lwpoint_to_wkb_buf:387] Endian set, buf = 0xc63e42
[lwout_wkb.c:integer_to_wkb_buf:189] Writing value '536870913'
[lwout_wkb.c:lwpoint_to_wkb_buf:390] Type set, buf = 0xc63e4a
[lwout_wkb.c:integer_to_wkb_buf:189] Writing value '4326'
[lwout_wkb.c:lwpoint_to_wkb_buf:395] SRID set, buf = 0xc63e52
[lwout_wkb.c:ptarray_to_wkb_buf:353] Writing point #0
[lwout_wkb.c:ptarray_to_wkb_buf:357] Writing dimension #0 (buf = 0xc63e52)
[lwout_wkb.c:ptarray_to_wkb_buf:357] Writing dimension #1 (buf = 0xc63e62)
[lwout_wkb.c:ptarray_to_wkb_buf:361] Done (buf = 0xc63e72)
[lwout_wkb.c:lwpoint_to_wkb_buf:399] Pointarray set, buf = 0xc63e72
[lwout_wkb.c:lwgeom_to_wkb:751] buf (0xc63e73) - wkb_out (0xc63e40) = 51
1: test2 = "0101000020E610000000000000000000000000000000000000" (typeid =
16391, len = -1, typmod = -1, byval = f)
Program received signal SIGSEGV, Segmentation fault.
0x000000000072488b in pfree (pointer=0xc63e40) at mcxt.c:659
659 (*header->context->methods->free_p) (header->context, pointer);
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.47.el6_2.9.x86_64 libxml2-2.7.6-4.el6_2.4.x86_64
proj-4.7.0-2.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x000000000072488b in pfree (pointer=0xc63e40) at mcxt.c:659
#1 0x0000000000458fc1 in debugtup (slot=0xc60c00, self=Unhandled dwarf
expression opcode 0xf3
) at printtup.c:549
#2 0x0000000000576ea2 in ExecutePlan (queryDesc=0xc604f0,
direction=Unhandled dwarf expression opcode 0xf3
) at execMain.c:1418
#3 standard_ExecutorRun (queryDesc=0xc604f0, direction=Unhandled dwarf
expression opcode 0xf3
) at execMain.c:301
#4 0x0000000000649570 in PortalRunSelect (portal=0xc5e4e0,
forward=Unhandled dwarf expression opcode 0xf3
) at pquery.c:944
#5 0x000000000064a880 in PortalRun (portal=0xc5e4e0,
count=9223372036854775807, isTopLevel=1 '\001', dest=0xb0ffa0,
altdest=0xb0ffa0, completionTag=0x7fffffffe2d0 "") at pquery.c:788
#6 0x0000000000646b07 in exec_simple_query (argc=Unhandled dwarf
expression opcode 0xf3
) at postgres.c:1046
#7 PostgresMain (argc=Unhandled dwarf expression opcode 0xf3
) at postgres.c:3958
#8 0x00000000005a7adb in main (argc=3, argv=0xb78b10) at main.c:197
I noticed that header->context->methods points (as do ->parent and ->name)
to an invalid address:
(gdb) f 0
#0 0x000000000072488b in pfree (pointer=0xc63e40) at mcxt.c:659
659 (*header->context->methods->free_p) (header->context, pointer);
(gdb) p *header->context
$8 = {type = 1237353800, methods = 0x7e01be000003c484, parent =
0x9a00e8c789480087, firstchild = 0xfa840fc08548ffd4, nextchild =
0x1c3883d0ff000002,
name = 0x279840fc58948 <Address 0x279840fc58948 out of bounds>, isReset =
0 '\000'}
(gdb) p *header->context->methods
Cannot access memory at address 0x7e01be000003c484
Suggestions?
I've attached the files with a slightly updated .c. The "Unhandled dwarf
expression opcode 0xf3" messages apparently mean my gdb is old, although it
is the latest in RHEL 6 repositories.
-Dave
On Thu, Jan 10, 2013 at 11:53 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Thu, Jan 10, 2013 at 10:57:08AM -0500, David Fuhry wrote:
>
> > I'm trying to write a C-Library function to return a PostGIS point.
> It's
> > crashing the backend when called:
> >
> > => select test2();
> > The connection to the server was lost. Attempting reset: Failed.
>
> [...]
>
> > #include "liblwgeom.h"
> >
> > PG_MODULE_MAGIC;
> >
> > /* This is needed by liblwgeom */
> > void lwgeom_init_allocators(void)
> > {
> > lwgeom_install_default_allocators();
> > }
>
> David, if you're using current trunk you'll need and explicit
> call to lwgeom_set_handlers() for registering allocators for liblwgeom.
> Simply defining lwgeom_init_allocators is not enough anymore.
>
> Note that failing to register the handlers will result in lwerror
> simply printing an error on stderr but not interrupting the control
> flow in your function body. I noticed there's no PG_RETURN_NULL()
> on error, it's a good practice to not assume lwerror throws an
> exception.
>
> --strk;
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130110/1bd7ff4f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 198 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130110/1bd7ff4f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.c
Type: text/x-csrc
Size: 656 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130110/1bd7ff4f/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.sql
Type: application/octet-stream
Size: 113 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130110/1bd7ff4f/attachment-0001.obj>
More information about the postgis-devel
mailing list