Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables - Mailing list pgsql-bugs
From | Tom Lane |
---|---|
Subject | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Date | |
Msg-id | 3979.1536433320@sss.pgh.pa.us Whole thread Raw |
In response to | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Responses |
Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
List | pgsql-bugs |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> Could it be that somehow, when libpq is loaded into the backend > Tom> address space as it is here, libpq winds up calling the backend's > Tom> copy of pg_saslprep rather than its own? > Yes, that is a thing that happens with ELF-style shared libs when you > dynamically load shared libraries that weren't linked with -Bsymbolic. If true, that's potentially pretty disastrous, because *every* src/port or src/common function that's used by libpq would be similarly subject to replacement by its backend version, and every behavioral difference between the frontend and backend coding would be a source of trouble. However, the info I can find about this suggests that it's only relevant for exported functions, not ones that are hidden by means of a version-script. Since libpq doesn't export pg_saslprep, this shouldn't be happening? But wait, this problem is being reported on OpenBSD. I wonder whether their linker behaves anything like Linux's ... hm, it looks like it *is* the same linker. I tried setting up a scram-auth-based postgres_fdw connection on my RHEL6 box and forcing it through the questionable code path by issuing a dummy ALTER USER MAPPING command from another session. It worked fine, so the problem doesn't seem to be present on Linux. Repeating the same thing on a nearby OpenBSD 6.0 image ... kaboom! It fails exactly as Jeremy describes. Furthermore, I can confirm that the attached patch fixes it. I wonder which other platforms we have that behave like this? And how come we've not seen symptoms before? It's hard to believe that src/common/saslprep.c is the only thing libpq imports that has FRONTEND-vs-not-FRONTEND behavior differences. regards, tom lane diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 95b82a6..1555be3 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -149,6 +149,11 @@ ifeq ($(PORTNAME), openbsd) ifdef soname LINK.shared += -Wl,-x,-soname,$(soname) endif + BUILD.exports = ( echo '{ global:'; $(AWK) '/^[^\#]/ {printf "%s;\n",$$1}' $<; echo ' local: *; };' ) >$@ + exports_file = $(SHLIB_EXPORTS:%.txt=%.list) + ifneq (,$(exports_file)) + LINK.shared += -Wl,--version-script=$(exports_file) + endif SHLIB_LINK += -lc else LINK.shared = $(LD) -x -Bshareable -Bforcearchive
pgsql-bugs by date: