Re: plruby: rb_iterate symbol clash with libruby.so

Hi,

On 2018-11-03 14:19:46 -0400, Tom Lane wrote:
> Pavel Raiskup <praiskup@redhat.com> writes:
> > Hi, I'm curious how it worked before (seems like the function is defined
> > in both PostgreSQL and Ruby projects for quite some time) - but I recently
> > came across this situation:
> >     - /bin/postgres is build-time linked with 'ld -E'
> >     - /bin/postgres dlopen()s plruby.so
> >     - plruby.so calls rb_iterate, but linker prefers rb_iterate defined in
> >       /bin/postgres, instead of (the wanted one) rb_iterate from libruby.so
> > This means an ugly PG server crash.  I'm curious what to do with this;
> > ideally it would be solvable from plruby.so itself, but there doesn't seem
> > to be nice solution (one could do some hacks with dlopen('libruby.so')).
> 
> Bleah.

ISTM this specific case we could solve the issue by opening plruby.so /
extension sos with RTLD_DEEPBIND.  That doesn't work if ruby extensions
that are loaded later use rb_iterate, but should work for the case above.


> We recently noticed that using a --version-script symbol filter on shared
> libraries fixes some cases of this problem, because a non-exported symbol
> will be preferentially resolved inside the library.  I guess that's of no
> use for this particular case though, since evidently Ruby has to export
> its rb_iterate for Ruby extensions to use.

I wondered every now and then if we shouldn't use dlmopen to open
extension objects, when available. If we were to do it right we'd create
a namespace for every shared object, use dlmopen to expose postgres'
symbols, and then load the extension objects in separate namespaces.
But I think that's not feasible, because:
"The glibc implementation supports a maximum of 16 namespaces."


> > Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
> > 'rbt_*' to avoid this clash?
> 
> That's not terribly appetizing, because it essentially means we're giving
> Ruby (and potentially every other library on the planet) veto power over
> our function namespace.  That does not scale, especially not when the
> feedback loop has a time constant measured in years :-(
> 
> I don't have a huge objection to renaming the rbtree functions, other
> than the precedent it sets ...

I don't mind the precedent that much, but isn't that also not unlikely
to break other extensions that use those functions?

Greetings,

Andres Freund