Polygon contrib

Hi everybody.

I've got a problem on a contrib i'm doing... unfortunatly, it will not
be under GPL because GPC, the library i'm using is "Free for not
commercial usage".

my contrib is to had a better # and ?# support on polygon type.

but if it work well as a part of postgres code, when i try to do it as a
contrib, it make postgres segfault..

i think it's because i use geo_ops.c specific syntax in contrib code,
but i'm not sure... can you help me to debug this ?

I send u the code of my contrib.. the interrestings things are at the
end of polygons_utils.c file.

Pierre-Yves Landuré
ps : take care to use a test database to apply this contrib if u try
it.. it will remove some existing operator (for polygons) in order to
replace them by mine.

pps : Thx for your help

Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> but if it work well as a part of postgres code, when i try to do it as a
> contrib, it make postgres segfault..

Segfault where? I'm not interested in reading through 90K of code
to try to spot a bug, but if you'd provide a stack trace it might
help narrow down the problem ...

regards, tom lane

Le jeu 08/08/2002 à 06:00, Tom Lane a écrit :
> Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> > but if it work well as a part of postgres code, when i try to do it as a
> > contrib, it make postgres segfault..
>
> Segfault where? I'm not interested in reading through 90K of code
> to try to spot a bug, but if you'd provide a stack trace it might
> help narrow down the problem ...

errr...whell it crash when i try to call one of the function defined in
the contrib.....

and, to ask a stupid question..... How can i do a stack trace ;))))
(yep.. i'm this bad ;)

Pierre-Yves Landsuré

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> and, to ask a stupid question..... How can i do a stack trace ;))))

Something like

gdb /path/to/postgres-executable /path/to/corefile
gdb> bt
gdb> quit

If you do not see a core file in the $PGDATA/base/yourdbnumber/
directory, you probably are running the postmaster with core dumps
disabled by ulimit. Try setting "ulimit -c unlimited" in the
script that starts it.

If the bt command produces a bunch of numbers and no routine names, you
need to recompile with debug symbols --- rerun configure adding
"--enable-debug", then rebuild and reinstall.

regards, tom lane

ok, will do that , thx for your help ;)

Pierre-Yves Landuré

Le jeu 08/08/2002 à 08:45, Tom Lane a écrit :
> Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> > and, to ask a stupid question..... How can i do a stack trace ;))))
>
> Something like
>
> gdb /path/to/postgres-executable /path/to/corefile
> gdb> bt
> gdb> quit
>
> If you do not see a core file in the $PGDATA/base/yourdbnumber/
> directory, you probably are running the postmaster with core dumps
> disabled by ulimit. Try setting "ulimit -c unlimited" in the
> script that starts it.
>
> If the bt command produces a bunch of numbers and no routine names, you
> need to recompile with debug symbols --- rerun configure adding
> "--enable-debug", then rebuild and reinstall.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Well, i've done it.. and here what it's doing :

There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-linux"...(no debugging symbols
found)...

warning: core file may not match specified executable file.
Core was generated by `postgres: postgres SaDAMS 127.0.0.1'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /usr/lib/libssl.so.0.9.6...(no debugging symbols
found)...
done.
Loaded symbols for /usr/lib/libssl.so.0.9.6
Reading symbols from /usr/lib/libcrypto.so.0.9.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.6
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libreadline.so.4...(no debugging symbols
found)...
done.
Loaded symbols for /lib/libreadline.so.4
Reading symbols from /lib/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libncurses.so.5...(no debugging symbols
found)...
done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
found)...
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/postgresql/lib/polygons_utils.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/postgresql/lib/polygons_utils.so
#0 0x08152bd9 in pg_detoast_datum ()
(gdb) bt
#0 0x08152bd9 in pg_detoast_datum ()
#1 0x4001ab72 in poly_center () from
/usr/lib/postgresql/lib/polygons_utils.so
#2 0x08151c5e in fmgr_internal_function ()
#3 0x080c50bd in ExecMakeFunctionResult ()
#4 0x080c5122 in ExecMakeFunctionResult ()
#5 0x080c56a0 in ExecEvalExpr ()
#6 0x080c5989 in ExecCleanTargetListLength ()
#7 0x080c5c1b in ExecProject ()
#8 0x080cb413 in ExecResult ()
#9 0x080c4119 in ExecProcNode ()
#10 0x080c30fe in ExecutorEnd ()
#11 0x080c2797 in ExecutorRun ()
#12 0x081104de in ProcessQuery ()
#13 0x0810ed70 in pg_exec_query_string ()
#14 0x0810fd5e in PostgresMain ()
#15 0x080f6d4e in ClosePostmasterPorts ()
#16 0x080f669f in ClosePostmasterPorts ()
#17 0x080f5882 in PostmasterMain ()
#18 0x080f5391 in PostmasterMain ()
#19 0x080d4e18 in main ()
#20 0x401d414f in __libc_start_main () from /lib/libc.so.6

As i was expecting, it seems to segfaut because i use postgres code
spectific constants such as :
PG_FUNCTION_ARGS

in my contrib.....
i was quite easy and handy, so i have no hesitation to do it... ;( but
then.. seems to not be working... ;(((

is there a easy solution to make it work in contrib librarys ?

Pierre-Yves Landuré

Le jeu 08/08/2002 à 08:49, Pierre-Yves LANDURE a écrit :
> ok, will do that , thx for your help ;)
>
> Pierre-Yves Landuré
>
> Le jeu 08/08/2002 à 08:45, Tom Lane a écrit :
> > Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> > > and, to ask a stupid question..... How can i do a stack trace ;))))
> >
> > Something like
> >
> > gdb /path/to/postgres-executable /path/to/corefile
> > gdb> bt
> > gdb> quit
> >
> > If you do not see a core file in the $PGDATA/base/yourdbnumber/
> > directory, you probably are running the postmaster with core dumps
> > disabled by ulimit. Try setting "ulimit -c unlimited" in the
> > script that starts it.
> >
> > If the bt command produces a bunch of numbers and no routine names, you
> > need to recompile with debug symbols --- rerun configure adding
> > "--enable-debug", then rebuild and reinstall.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> (gdb) bt
> #0 0x08152bd9 in pg_detoast_datum ()
> #1 0x4001ab72 in poly_center () from
> /usr/lib/postgresql/lib/polygons_utils.so
> #2 0x08151c5e in fmgr_internal_function ()
> #3 0x080c50bd in ExecMakeFunctionResult ()

Hm. And the query that triggers this is what exactly?

Judging from the stack trace, this cannot be poly_center's fault
directly. It looks like a bad input value is being passed to
poly_center and then to pg_detoast_datum. I'm wondering whether
the bad value is a NULL ... if so, your mistake is not to have
marked the CREATE FUNCTION command "isStrict". The internally-defined
functions you've copied are all marked strict so that they don't
have to think about null inputs.

regards, tom lane

The used query is :

SELECT @@polygon(box '((120,-10),(160,15))')

it's a query that use a C code which normally is not bug.. ;)

Pierre-Yves Landuré

Le jeu 08/08/2002 à 09:20, Tom Lane a écrit :
> Pierre-Yves LANDURE <pylandur(at)ifremer(dot)fr> writes:
> > (gdb) bt
> > #0 0x08152bd9 in pg_detoast_datum ()
> > #1 0x4001ab72 in poly_center () from
> > /usr/lib/postgresql/lib/polygons_utils.so
> > #2 0x08151c5e in fmgr_internal_function ()
> > #3 0x080c50bd in ExecMakeFunctionResult ()
>
> Hm. And the query that triggers this is what exactly?
>
> Judging from the stack trace, this cannot be poly_center's fault
> directly. It looks like a bad input value is being passed to
> poly_center and then to pg_detoast_datum. I'm wondering whether
> the bad value is a NULL ... if so, your mistake is not to have
> marked the CREATE FUNCTION command "isStrict". The internally-defined
> functions you've copied are all marked strict so that they don't
> have to think about null inputs.
>
> regards, tom lane