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
Attachments:
Pierre-Yves LANDURE <pylandur@ifremer.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@ifremer.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é
Show quoted text
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Pierre-Yves LANDURE <pylandur@ifremer.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 :
Show quoted text
Pierre-Yves LANDURE <pylandur@ifremer.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> quitIf 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 :
Show quoted text
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@ifremer.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> quitIf 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?
Pierre-Yves LANDURE <pylandur@ifremer.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 :
Show quoted text
Pierre-Yves LANDURE <pylandur@ifremer.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