C/C++ Linker Problem in Postgres extension functions - Mailing list pgsql-admin
From | Craig James |
---|---|
Subject | C/C++ Linker Problem in Postgres extension functions |
Date | |
Msg-id | CAFwQ8rcg4hpFYLr+UcLtcpyZj=uhK2SXG9TFO66Tqw1wj0047g@mail.gmail.com Whole thread Raw |
List | pgsql-admin |
I recently recompiled our Postgres extension functions and re-encountered a problem that I thought was solved. When I call our function, the code just hangs ... it sit there not executing, not using any CPU cycles. Forever. The process is still running, but seems to be waiting for ... what?
I originally fixed this problem by using g++ instead of gcc to invoke the linking step for our .so shared object file. It seems that g++ knows how to invoke the C++ initialization code, whereas gcc doesn't. Since Postgres is written in C, linking a C++ library didn't work until I switched to g++ to do the linking.
However ... now it's not working any more, for no apparent reason. The stack trace below shows what I find when I attach to the running Postgres process using gdb.
I ran valgrind on a test program that calls this exact same function and it says the function is clean -- no memory errors or leaks.
Has anyone seen a problem like this when building Postgres extensions? This is Postgres 8.4.10.
Thanks,
Craig
0x00007fdfd755816e in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00007fdfd755816e in ?? () from /lib/libc.so.6
#1 0x00007fdfd74e13dc in ?? () from /lib/libc.so.6
#2 0x00007fdfd74dfe78 in free () from /lib/libc.so.6
#3 0x00007fdfd7c7e722 in ?? () from /lib64/ld-linux-x86-64.so.2
#4 0x00007fdfd7c795e5 in ?? () from /lib64/ld-linux-x86-64.so.2
#5 0x00007fdfd7c7f5f5 in ?? () from /lib64/ld-linux-x86-64.so.2
#6 0x00007fdfd7c7a986 in ?? () from /lib64/ld-linux-x86-64.so.2
#7 0x00007fdfd7c7efba in ?? () from /lib64/ld-linux-x86-64.so.2
#8 0x00007fdfd7586be0 in ?? () from /lib/libc.so.6
#9 0x00007fdfd7c7a986 in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x00007fdfd7586d37 in __libc_dlopen_mode () from /lib/libc.so.6
#11 0x00007fdfd75613f1 in backtrace () from /lib/libc.so.6
#12 0x00007fdfd74cf50f in ?? () from /lib/libc.so.6
#13 0x00007fdfd74d95b6 in ?? () from /lib/libc.so.6
#14 0x00007fdfd74dfe83 in free () from /lib/libc.so.6
#15 0x00007fdf95de56ac in __gnu_cxx::new_allocator<OpenBabel::OBRing*>::deallocate (this=0xfc2b88, __p=0xff8ab0)
at /usr/include/c++/4.4/ext/new_allocator.h:95
#16 0x00007fdf95de413c in std::_Vector_base<OpenBabel::OBRing*, std::allocator<OpenBabel::OBRing*> >::_M_deallocate (
this=0xfc2b88, __p=0xff8ab0, __n=2) at /usr/include/c++/4.4/bits/stl_vector.h:146
#17 0x00007fdf95de3e37 in ~_Vector_base (this=0xfc2b88, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4/bits/stl_vector.h:132
#18 0x00007fdf95de2e82 in ~vector (this=0xfc2b88, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4/bits/stl_vector.h:313
#19 0x00007fdf959977da in ~OBRingData (this=0xfc2b70, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/src/generic.cpp:784
#20 0x00007fdf95907d83 in ~OBBase (this=0xfc1c40, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/include/openbabel/base.h:249
#21 0x00007fdf95a13c1b in ~OBMol (this=0xfc1c40, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/src/mol.cpp:3225
#22 0x00007fdf95decf5f in emol_ichem_mol_dealloc (mol_ob=0xfc1c40) at openbabel2.3/postgres_mol_openbabel.cpp:190
#23 0x00007fdf95ded864 in emol_ichem_normalize (length=25, molecule_text=0xf90bcc "Br.Br.Oc1ccc(cc1)N1CCNCC1",
intype_len=3, intype=0x7fdf95df2fa9 "SDF", outtype_len=3, outtype=0x7fdf95df2fa9 "SDF")
at openbabel2.3/postgres_mol_openbabel.cpp:461
#24 0x00007fdf95df1ef5 in emol_normalize_sdf (fcinfo=0x7fff2369dcc0) at postgres_mol.c:553
#25 0x000000000054c815 in ExecMakeFunctionResult ()
#26 0x000000000054795c in ExecEvalExprSwitchContext ()
#27 0x00000000005ac003 in evaluate_expr ()
#28 0x00000000005ad932 in simplify_function ()
#29 0x00000000005ae339 in eval_const_expressions_mutator ()
#30 0x0000000000570129 in expression_tree_mutator ()
#31 0x00000000005ae03c in eval_const_expressions_mutator ()
#32 0x000000000057068b in expression_tree_mutator ()
#33 0x00000000005ae03c in eval_const_expressions_mutator ()
#34 0x00000000005af3ef in eval_const_expressions ()
#35 0x000000000059ffcd in preprocess_expression ()
#36 0x00000000005a28bd in subquery_planner ()
#37 0x00000000005a2c5f in standard_planner ()
#38 0x00000000005ebb5a in pg_plan_query ()
#39 0x00000000005ebc44 in pg_plan_queries ()
#40 0x00000000005ec0d7 in exec_simple_query ()
#41 0x00000000005ed677 in PostgresMain ()
#42 0x00000000005c15ab in ServerLoop ()
#43 0x00000000005c3a9c in PostmasterMain ()
#44 0x000000000056e530 in main ()
I originally fixed this problem by using g++ instead of gcc to invoke the linking step for our .so shared object file. It seems that g++ knows how to invoke the C++ initialization code, whereas gcc doesn't. Since Postgres is written in C, linking a C++ library didn't work until I switched to g++ to do the linking.
However ... now it's not working any more, for no apparent reason. The stack trace below shows what I find when I attach to the running Postgres process using gdb.
I ran valgrind on a test program that calls this exact same function and it says the function is clean -- no memory errors or leaks.
Has anyone seen a problem like this when building Postgres extensions? This is Postgres 8.4.10.
Thanks,
Craig
0x00007fdfd755816e in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00007fdfd755816e in ?? () from /lib/libc.so.6
#1 0x00007fdfd74e13dc in ?? () from /lib/libc.so.6
#2 0x00007fdfd74dfe78 in free () from /lib/libc.so.6
#3 0x00007fdfd7c7e722 in ?? () from /lib64/ld-linux-x86-64.so.2
#4 0x00007fdfd7c795e5 in ?? () from /lib64/ld-linux-x86-64.so.2
#5 0x00007fdfd7c7f5f5 in ?? () from /lib64/ld-linux-x86-64.so.2
#6 0x00007fdfd7c7a986 in ?? () from /lib64/ld-linux-x86-64.so.2
#7 0x00007fdfd7c7efba in ?? () from /lib64/ld-linux-x86-64.so.2
#8 0x00007fdfd7586be0 in ?? () from /lib/libc.so.6
#9 0x00007fdfd7c7a986 in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x00007fdfd7586d37 in __libc_dlopen_mode () from /lib/libc.so.6
#11 0x00007fdfd75613f1 in backtrace () from /lib/libc.so.6
#12 0x00007fdfd74cf50f in ?? () from /lib/libc.so.6
#13 0x00007fdfd74d95b6 in ?? () from /lib/libc.so.6
#14 0x00007fdfd74dfe83 in free () from /lib/libc.so.6
#15 0x00007fdf95de56ac in __gnu_cxx::new_allocator<OpenBabel::OBRing*>::deallocate (this=0xfc2b88, __p=0xff8ab0)
at /usr/include/c++/4.4/ext/new_allocator.h:95
#16 0x00007fdf95de413c in std::_Vector_base<OpenBabel::OBRing*, std::allocator<OpenBabel::OBRing*> >::_M_deallocate (
this=0xfc2b88, __p=0xff8ab0, __n=2) at /usr/include/c++/4.4/bits/stl_vector.h:146
#17 0x00007fdf95de3e37 in ~_Vector_base (this=0xfc2b88, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4/bits/stl_vector.h:132
#18 0x00007fdf95de2e82 in ~vector (this=0xfc2b88, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4/bits/stl_vector.h:313
#19 0x00007fdf959977da in ~OBRingData (this=0xfc2b70, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/src/generic.cpp:784
#20 0x00007fdf95907d83 in ~OBBase (this=0xfc1c40, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/include/openbabel/base.h:249
#21 0x00007fdf95a13c1b in ~OBMol (this=0xfc1c40, __in_chrg=<value optimized out>)
at /home/cjames/openbabel-2.3.x-r4744/source/src/mol.cpp:3225
#22 0x00007fdf95decf5f in emol_ichem_mol_dealloc (mol_ob=0xfc1c40) at openbabel2.3/postgres_mol_openbabel.cpp:190
#23 0x00007fdf95ded864 in emol_ichem_normalize (length=25, molecule_text=0xf90bcc "Br.Br.Oc1ccc(cc1)N1CCNCC1",
intype_len=3, intype=0x7fdf95df2fa9 "SDF", outtype_len=3, outtype=0x7fdf95df2fa9 "SDF")
at openbabel2.3/postgres_mol_openbabel.cpp:461
#24 0x00007fdf95df1ef5 in emol_normalize_sdf (fcinfo=0x7fff2369dcc0) at postgres_mol.c:553
#25 0x000000000054c815 in ExecMakeFunctionResult ()
#26 0x000000000054795c in ExecEvalExprSwitchContext ()
#27 0x00000000005ac003 in evaluate_expr ()
#28 0x00000000005ad932 in simplify_function ()
#29 0x00000000005ae339 in eval_const_expressions_mutator ()
#30 0x0000000000570129 in expression_tree_mutator ()
#31 0x00000000005ae03c in eval_const_expressions_mutator ()
#32 0x000000000057068b in expression_tree_mutator ()
#33 0x00000000005ae03c in eval_const_expressions_mutator ()
#34 0x00000000005af3ef in eval_const_expressions ()
#35 0x000000000059ffcd in preprocess_expression ()
#36 0x00000000005a28bd in subquery_planner ()
#37 0x00000000005a2c5f in standard_planner ()
#38 0x00000000005ebb5a in pg_plan_query ()
#39 0x00000000005ebc44 in pg_plan_queries ()
#40 0x00000000005ec0d7 in exec_simple_query ()
#41 0x00000000005ed677 in PostgresMain ()
#42 0x00000000005c15ab in ServerLoop ()
#43 0x00000000005c3a9c in PostmasterMain ()
#44 0x000000000056e530 in main ()
pgsql-admin by date: