[postgis-devel] C-Library function returning PostGIS point crashing backend

David Fuhry dfuhry at gmail.com
Mon Jan 14 19:19:52 PST 2013 

Not sure if this reveals anything more, but here's the valgrind output.
Apparently the segfault is of reading 16 bytes before the memory location
malloced in lwgeom_to_wkb, I don't know if that's a coincidence or not.


$ PGDATA=/mnt/drive2/postgres/main valgrind postgres --single dfuhry
==31998== Memcheck, a memory error detector
==31998== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31998== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==31998== Command: postgres --single dfuhry
==31998==
==31998== Conditional jump or move depends on uninitialised value(s)
==31998==    at 0x3D85D32EB2: __strspn_sse42 (in /lib64/libc-2.12.so)
==31998==    by 0x6FF052: RelationCacheInitFileRemove (relcache.c:4589)
==31998==    by 0x49B737: StartupXLOG (xlog.c:6195)
==31998==    by 0x7140B4: InitPostgres (postinit.c:522)
==31998==    by 0x6464E4: PostgresMain (postgres.c:3682)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==
==31998== Conditional jump or move depends on uninitialised value(s)
==31998==    at 0x6FF061: RelationCacheInitFileRemove (relcache.c:4589)
==31998==    by 0x49B737: StartupXLOG (xlog.c:6195)
==31998==    by 0x7140B4: InitPostgres (postinit.c:522)
==31998==    by 0x6464E4: PostgresMain (postgres.c:3682)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==
==31998== Syscall param write(buf) points to uninitialised byte(s)
==31998==    at 0x3D85CDAE60: __write_nocancel (in /lib64/libc-2.12.so)
==31998==    by 0x3D85C71582: _IO_file_write@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C72B34: _IO_do_write@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C711FC: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C6760C: fwrite (in /lib64/libc-2.12.so)
==31998==    by 0x6FAD87: write_item (relcache.c:4468)
==31998==    by 0x6FAF56: write_relcache_init_file (relcache.c:4360)
==31998==    by 0x6FDD69: RelationCacheInitializePhase3 (relcache.c:3068)
==31998==    by 0x71452E: InitPostgres (postinit.c:824)
==31998==    by 0x6464E4: PostgresMain (postgres.c:3682)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==  Address 0x4c0c5d2 is not stack'd, malloc'd or (recently) free'd
==31998==
==31998== Syscall param write(buf) points to uninitialised byte(s)
==31998==    at 0x3D85CDAE60: __write_nocancel (in /lib64/libc-2.12.so)
==31998==    by 0x3D85C71582: _IO_file_write@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C72B34: _IO_do_write@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C7230F: _IO_file_close_it@@GLIBC_2.2.5 (in /lib64/
libc-2.12.so)
==31998==    by 0x3D85C660B7: fclose@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==31998==    by 0x627C22: FreeDesc (fd.c:1533)
==31998==    by 0x6FAFE7: write_relcache_init_file (relcache.c:4418)
==31998==    by 0x6FDD70: RelationCacheInitializePhase3 (relcache.c:3069)
==31998==    by 0x71452E: InitPostgres (postinit.c:824)
==31998==    by 0x6464E4: PostgresMain (postgres.c:3682)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==  Address 0x4c0c0aa is not stack'd, malloc'd or (recently) free'd
==31998==

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(0x5023290)
uint8_t(0x5023608)
[g_serialized.c:gserialized_from_lwpoint:445]
lwpoint_to_gserialized(0x5023290, 0x5023608) 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 = 0xe812590
[lwout_wkb.c:lwpoint_to_wkb_buf:387] Endian set, buf = 0xe812592
[lwout_wkb.c:integer_to_wkb_buf:189] Writing value '536870913'
[lwout_wkb.c:lwpoint_to_wkb_buf:390] Type set, buf = 0xe81259a
[lwout_wkb.c:integer_to_wkb_buf:189] Writing value '4326'
[lwout_wkb.c:lwpoint_to_wkb_buf:395] SRID set, buf = 0xe8125a2
[lwout_wkb.c:ptarray_to_wkb_buf:353] Writing point #0
[lwout_wkb.c:ptarray_to_wkb_buf:357] Writing dimension #0 (buf = 0xe8125a2)
[lwout_wkb.c:ptarray_to_wkb_buf:357] Writing dimension #1 (buf = 0xe8125b2)
[lwout_wkb.c:ptarray_to_wkb_buf:361] Done (buf = 0xe8125c2)
[lwout_wkb.c:lwpoint_to_wkb_buf:399] Pointarray set, buf = 0xe8125c2
[lwout_wkb.c:lwgeom_to_wkb:751] buf (0xe8125c3) - wkb_out (0xe812590) = 51
 1: test2 = "0101000020E610000000000000000000000000000000000000" (typeid =
16391, len = -1, typmod = -1, byval = f)
==31998== Invalid read of size 8
==31998==    at 0x724883: pfree (mcxt.c:659)
==31998==    by 0x458FC0: debugtup (printtup.c:549)
==31998==    by 0x576EA1: standard_ExecutorRun (execMain.c:1418)
==31998==    by 0x64956F: PortalRunSelect (pquery.c:944)
==31998==    by 0x64A87F: PortalRun (pquery.c:788)
==31998==    by 0x646B06: PostgresMain (postgres.c:1046)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==  Address 0xe812580 is 16 bytes before a block of size 51 alloc'd
==31998==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==31998==    by 0xDAC8E8B: lwgeom_to_wkb (lwout_wkb.c:729)
==31998==    by 0xDA8D3D3: LWGEOM_out (lwgeom_inout.c:237)
==31998==    by 0x70CCF2: FunctionCall1Coll (fmgr.c:1300)
==31998==    by 0x70E02C: OutputFunctionCall (fmgr.c:1953)
==31998==    by 0x70E24A: OidOutputFunctionCall (fmgr.c:2056)
==31998==    by 0x458F9C: debugtup (printtup.c:545)
==31998==    by 0x576EA1: standard_ExecutorRun (execMain.c:1418)
==31998==    by 0x64956F: PortalRunSelect (pquery.c:944)
==31998==    by 0x64A87F: PortalRun (pquery.c:788)
==31998==    by 0x646B06: PostgresMain (postgres.c:1046)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==
==31998== Invalid read of size 8
==31998==    at 0x724887: pfree (mcxt.c:659)
==31998==    by 0x458FC0: debugtup (printtup.c:549)
==31998==    by 0x576EA1: standard_ExecutorRun (execMain.c:1418)
==31998==    by 0x64956F: PortalRunSelect (pquery.c:944)
==31998==    by 0x64A87F: PortalRun (pquery.c:788)
==31998==    by 0x646B06: PostgresMain (postgres.c:1046)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==31998==
==31998==
==31998== Process terminating with default action of signal 11 (SIGSEGV)
==31998==  Access not within mapped region at address 0x8
==31998==    at 0x724887: pfree (mcxt.c:659)
==31998==    by 0x458FC0: debugtup (printtup.c:549)
==31998==    by 0x576EA1: standard_ExecutorRun (execMain.c:1418)
==31998==    by 0x64956F: PortalRunSelect (pquery.c:944)
==31998==    by 0x64A87F: PortalRun (pquery.c:788)
==31998==    by 0x646B06: PostgresMain (postgres.c:1046)
==31998==    by 0x5A7ADA: main (main.c:197)
==31998==  If you believe this happened as a result of a stack
==31998==  overflow in your program's main thread (unlikely but
==31998==  possible), you can try to increase the size of the
==31998==  main thread stack using the --main-stacksize= flag.
==31998==  The main thread stack size used in this run was 10485760.
==31998==
==31998== HEAP SUMMARY:
==31998==     in use at exit: 1,326,373 bytes in 298 blocks
==31998==   total heap usage: 740 allocs, 442 frees, 4,165,235 bytes
allocated
==31998==
==31998== LEAK SUMMARY:
==31998==    definitely lost: 315 bytes in 4 blocks
==31998==    indirectly lost: 2,211 bytes in 29 blocks
==31998==      possibly lost: 0 bytes in 0 blocks
==31998==    still reachable: 1,323,847 bytes in 265 blocks
==31998==         suppressed: 0 bytes in 0 blocks
==31998== Rerun with --leak-check=full to see details of leaked memory
==31998==
==31998== For counts of detected and suppressed errors, rerun with: -v
==31998== Use --track-origins=yes to see where uninitialised values come
from
==31998== ERROR SUMMARY: 31 errors from 6 contexts (suppressed: 30 from 9)
Segmentation fault (core dumped)


-Dave



On Mon, Jan 14, 2013 at 4:14 AM, Sandro Santilli <strk at keybit.net> wrote:

> On Fri, Jan 11, 2013 at 05:20:55PM -0500, David Fuhry wrote:
> > I tried statically linking liblwgeom by changing SHLIB_LINK from
> > "-L/usr/local/lib -llwgeom" to "/usr/local/lib/liblwgeom.a" but the
> > segfault in pfree occurred just as before.
>
> Try asking valgrind about it ?
>
> --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/20130114/f583ad26/attachment.html>

More information about the postgis-devel mailing list