Обсуждение: 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@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é > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
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 : > 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 > > ---------------------------(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@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 > > > > ---------------------------(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@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 : > 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