Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Thomas, does that mean the bug is still there?

Regards,
Mike Yeap

On Mon, Feb 25, 2019 at 4:06 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap <wkk1020(at)gmail(dot)com> wrote:
> > openldap-clients.x86_64 2.4.44-21.el7_6
> @updates
> > openldap-devel.i686 2.4.44-21.el7_6
> updates
> > openldap-devel.x86_64 2.4.44-21.el7_6
> updates
> > openldap.i686 2.4.44-21.el7_6
> updates
> > openldap-servers-sql.x86_64 2.4.44-21.el7_6
> updates
> > openldap-servers.x86_64 2.4.44-21.el7_6
> updates
> > openldap.x86_64 2.4.44-21.el7_6
> @updates
>
> > On Wed, Feb 20, 2019 at 10:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
> >> backends can crash at exit. Raise a warning during "configure"
> based on
> >> the compile-time OpenLDAP version number, and test the crash
> scenario in
> >> the dblink test suite. Back-patch to 9.0 (all supported versions).
>
> Clearly 2.4.44 is not in the range 2.4.24 through 2.4.31. Perhaps the
> dangerous range is out of date? Hmm, so Noah's analysis[1] says this
> is a clash between libldap_r.so (used by libpq) and libldap.so (used
> by the server), specifically in destructor/exit code. Curiously, in a
> thread about Curl's struggles with this problem, I found a claim[2]
> that Debian decided to abandon the non-"_r" variant and just use _r
> always. Sure enough, on my Debian buster VM I see a symlink
> libldap-2.4.so.2 -> libldap_r-2.4.so.2. So essentially Debian and
> friends have already forced Noah's first option on users:
>
> > 1. Link the backend with libldap_r, so we never face the mismatch. On
> some
> > platforms, this means also linking in threading libraries.
>
> FreeBSD and CentOS systems near me have separate libraries still.
>
> [1]
> https://www.postgresql.org/message-id/flat/20140612210219.GA705509%40tornado.leadboat.com
> [2] https://www.openldap.org/lists/openldap-technical/201608/msg00094.html
>
> --
> Thomas Munro
> https://enterprisedb.com
>