"Merlin Moncure" <mmoncure@gmail.com> writes:
> ok, an update on this. we actually covered up the bug in reducing the
> problem to our test case. our make system used cp -f to overwite the
> .so file in use by postgresql.
With that I can reproduce it --- I think it is a glibc bug. The crash
occurs inside dlsym() while trying to look up "_PG_fini".
(gdb) bt
#0 0x0000003bf1a08b31 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1 0x0000003bf1a08e6f in _dl_lookup_symbol_x ()
from /lib64/ld-linux-x86-64.so.2
#2 0x0000003bf1cff5ee in do_sym () from /lib64/libc.so.6
#3 0x0000003bf2101334 in dlsym_doit () from /lib64/libdl.so.2
#4 0x0000003bf1a0ca36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5 0x0000003bf210173d in _dlerror_run () from /lib64/libdl.so.2
#6 0x0000003bf21012ea in dlsym () from /lib64/libdl.so.2
#7 0x000000000061f414 in load_file (filename=Variable "filename" is not available.
) at dfmgr.c:352
#8 0x00000000005a3d4c in PortalRunUtility (portal=0x98a828, query=0x9564f0,
dest=0x956798, completionTag=0x7fffb624e4e0 "") at pquery.c:1063
I'd suggest putting together a simple stand-alone test case and filing
a bug report against glibc. You probably just need
dlopen(...);
system("cp -f over the .so file");
dlsym(...);
regards, tom lane
