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.