segfault with st_numgeometries when --enable-debug

[pramsey]

What steps will reproduce the problem?

1. compile postgis with —enable-debug
2. run select st_numgeometries(the_geom) on thetable limit 1

where the_geom is a multi* geometry column

[pramsey]

Update, this bug is very hard to create, it only occurs when st_numgeometries is the very first function to exercise the notice handler, which probably only occurs when you're doing things like run postgres in single user mode.

gdb postgres run —single postgisdb select st_numgeometries(the_geom) from thetable limit 1

! segfault !<

but, if you first run a function that works, like st_area, and *then* run st_numgeometries, everything works fine.

[mcayland]

Gah. After a couple of hours of debugging, I can see what's happening - the new functions in SVN that perform the switch between malloc/palloc etc. assume that you can perform a variadic passthrough which isn't possible.

This is my fault - it'll take a little while, but I'll go fix it up so you guys can carry on debugging without crashing PostGIS.

ATB,

Mark.

[mcayland]

Okay, I've finally committed a solution for this to SVN trunk. Please do an 'svn up' followed by a complete 'make clean' / 'make install' cycle since I had to refactor the liblwgeom memory API a little in order to make this work.

Paul, can you confirm that this resolves the issue for you?

ATB,

Mark.

[pramsey]

It's actually worse… now running st_area also causes a segfault.

(gdb) run —single postgis Starting program: /usr/local/pgsql/8.3/bin/postgres —single postgis

PostgreSQL stand-alone backend 8.3.3 backend> select st_area(the_geom) from va limit 1;

1: st_area (typeid = 701, len = 8, typmod = -1, byval = f)

——

Program received signal SIGSEGV, Segmentation fault. 0x00912fd3 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00912fd3 in strlen () from /lib/libc.so.6 #1 0x005c6461 in lw_vasprintf (result=0xbffbe0a0, format=0x5d17d2 's:%s:%d] lwgeom_inspect: serialized@%p', args=0xbffbe0e4 '�\030]')

at vsprintf.c:121

#2 0x00583dd7 in pg_notice (fmt=0x5d17d0 '[%s:%s:%d] lwgeom_inspect: serialized@%p', ap=0xbffbe0e4 '�\030]') at lwgeom_pg.c:83 #3 0x005bd9da in lwnotice (fmt=0x5d17d0 '[%s:%s:%d] lwgeom_inspect: serialized@%p') at lwutil.c:59 #4 0x005b5ab3 in lwgeom_inspect (serialized_form=0xb5a5901c '�I
\233I�}�H_v\233I���H�\v') at lwgeom_api.c:929 #5 0x00596fc7 in LWGEOM_area_polygon (fcinfo=0xbffbe1c8) at lwgeom_functions_basic.c:324 #6 0x0815b786 in ExecMakeFunctionResult (fcache=0x851a790, econtext=0x851a720, isNull=0x851b270 , isDone=0x851b280) at execQual.c:1351 #7 0x0815bb98 in ExecEvalFunc (fcache=0x851a790, econtext=0x851a720, isNull=0x851b270 , isDone=0x851b280) at execQual.c:1753 #8 0x0815994a in ExecProject (projInfo=0x851b188, isDone=0xbffbe498) at execQual.c:4601 #9 0x0815f95c in ExecScan (node=0x851a698, accessMtd=0x8169e5a <SeqNext>) at execScan.c:143 #10 0x08169e58 in ExecSeqScan (node=0x851a698) at nodeSeqscan.c:130 #11 0x08159273 in ExecProcNode (node=0x851a698) at execProcnode.c:334 #12 0x0816adfd in ExecLimit (node=0x851a588) at nodeLimit.c:89 #13 0x0815936a in ExecProcNode (node=0x851a588) at execProcnode.c:410 #14 0x0815829a in ExecutorRun (queryDesc=0x8519f18, direction=ForwardScanDirection, count=0) at execMain.c:1248 #15 0x081e8b0a in PortalRunSelect (portal=0x8511128, forward≤value optimized out>, count=0, dest=0x8353050) at pquery.c:943 #16 0x081e9beb in PortalRun (portal=0x8511128, count=2147483647, isTopLevel=1 '\001', dest=0x8353050, altdest=0x8353050, completionTag=0xbffbe73a )

at pquery.c:769

#17 0x081e54d6 in exec_simple_query (query_string=0x84e1218 'select st_area(the_geom) from va limit 1;\n') at postgres.c:986 #18 0x081e6bb1 in PostgresMain (argc=2, argv≤value optimized out>, username=0x847ee98 'postgres') at postgres.c:3572 #19 0x08177a5a in main (argc=3, argv=Cannot access memory at address 0x4 ) at main.c:186

[mcayland]

Drat. It looks like the va_args() structure is not quite right in your case - are you developing on a platform that isn't Linux per-chance?

[pramsey]

This error is on Centos 5.1. I haven't checked to see if it also happens in OS/X.

[mcayland]

Ah. I think it's a difference between 32 bit and 64 bit compiler ABIs - once is pass by reference while the other is pass by value. Using va_copy() seems to do the right thing - can you quickly test after an 'svn up / make clean / make install'?

Many thanks,

Mark.

[pramsey]

That got it. Back in bidniss baby.

[mcayland]

Marking as fixed.

ATB,

Mark.