Percona Server with XtraDB

Postfix crashes using shared dependency(libmysqlclient.so) provided by Percona Server-shared-compat / Percona-Server-shared in CentOS/RHEL 6.x

Reported by Jaime Sicam on 2012-07-24
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server
High
Ignacio Nin
5.1
High
Ignacio Nin
5.5
High
Ignacio Nin

Bug Description

Postfix version:
postfix-2.6.6-2.2.el6_1.x86_64

Percona Server version:
Percona-Server-server-51-5.1.63-rel13.4.443.rhel6.x86_64
Percona-Server-client-51-5.1.63-rel13.4.443.rhel6.x86_64
Percona-Server-shared-51-5.1.63-rel13.4.443.rhel6.x86_64

Log:
Jul 23 11:00:23 server postfix/master[12809]: warning: process /usr/libexec/postfix/smtp pid 12878 killed by signal 11
Jul 23 11:00:23 server postfix/master[12809]: warning: /usr/libexec/postfix/smtp: bad command startup -- throttling
Jul 23 11:00:23 server postfix/error[12879]: 6600DF404B7: to=<***@***.com>, relay=none, delay=2369, delays=2369/0.2/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)

Core dump:
Program terminated with signal 11, Segmentation fault.
#0 0x00007f8174859118 in main_arena () from /lib64/libc-2.12.so

Thread 1 (Thread 0x7f8176b2c7c0 (LWP 13678)):
#0 0x00007f8174859118 in main_arena () from /lib64/libc-2.12.so
#1 0x00007f81754d57f7 in EVP_CIPHER_CTX_cleanup (c=0x7f81781486f0) at
evp_enc.c:569
#2 0x00007f81754d6265 in EVP_CipherInit_ex (ctx=0x7f81781486f0,
cipher=0x7f8175796b00, impl=0x0, key=0x7f8178148a68
"߰6\240\350\205\377\211\023\352\223\271\"N\n\232|Xe\006\342S\031{\202\372\250|<\016\343\037\203\266\212kQ\260\311ڣ\340>+\367{\033\034\213;%.\226GH\033F\351m55\330\002\222Kx뤾h\254\221\356X&\322\305\375\356\f\264YûM=J\374\340=!\v\024\313\002<؎\205t\201\177",
iv=0x7f8178148aa8
"Kx뤾h\254\221\356X&\322\305\375\356\f\264YûM=J\374\340=!\v\024\313\002<؎\205t\201\177",
enc=1) at evp_enc.c:171
#3 0x00007f81757de1d6 in tls1_change_cipher_state (s=0x7f8178126980,
which=18) at t1_enc.c:501
#4 0x00007f81757d37db in ssl3_connect (s=0x7f8178126980) at s3_clnt.c:449
#5 0x00007f8176b67827 in tls_bio (fd=13, timeout=300,
TLScontext=0x7f817811f2f0, hsfunc=0x7f81757e8310 <SSL_connect>, rfunc=0,
wfunc=0, buf=0x0, num=0) at tls_bio_ops.c:266
#6 0x00007f8176b66465 in tls_client_start (props=0x7fffe71463d0) at
tls_client.c:903
#7 0x00007f8176b5f317 in smtp_start_tls (state=0x7f8178121910) at
smtp_proto.c:746
#8 smtp_helo (state=0x7f8178121910) at smtp_proto.c:632
#9 0x00007f8176b5c081 in smtp_connect_remote (state=0x7f8178121910,
nexthop=<value optimized out>, def_service=0x7f8176b9ad87 "smtp") at
smtp_connect.c:887
#10 0x00007f8176b5c907 in smtp_connect (state=0x7f8178121910) at
smtp_connect.c:1041
#11 0x00007f8176b5b202 in deliver_message (client_stream=0x7f817811f5e0,
service=0x7fffe7147f8c "smtp", argv=<value optimized out>) at smtp.c:854
#12 smtp_service (client_stream=0x7f817811f5e0, service=0x7fffe7147f8c
"smtp", argv=<value optimized out>) at smtp.c:886
#13 0x00007f8176b65827 in single_server_wakeup (fd=<value optimized out>)
at single_server.c:262
#14 0x00007f8176b8c0b7 in event_loop (delay=<value optimized out>) at
events.c:1086
#15 0x00007f8176b6560a in single_server_main (argc=<value optimized out>,
argv=<value optimized out>, service=0x7f8176b5b160 <smtp_service>) at
single_server.c:732
#16 0x00007f8176b5ac69 in main (argc=4, argv=0x7fffe7146fb8) at smtp.c:1093

Workaround:
https://groups.google.com/forum/?fromgroups#!topic/mailing.postfix.users/uGKF4NL4X64

Jaime Sicam (jssicam) on 2012-07-24
description: updated

The bug is not related to postfix per se, but rather is that our libmysqlclient is somehow incompatible with the upstream-provided one.

tags: added: pkg
Download full text (3.5 KiB)

Able to reproduce with both PS 5.1 and PS 5.5:

rpm -qa | grep -iE 'mysql|percona|postfix'
    perl-DBD-MySQL-4.013-3.el6.x86_64
    Percona-Server-server-51-5.1.65-rel14.0.475.rhel6.x86_64
    postfix-debuginfo-2.6.6-2.2.el6_1.x86_64
    Percona-Server-shared-51-5.1.65-rel14.0.475.rhel6.x86_64
    percona-xtrabackup-2.0.2-461.rhel6.x86_64
    percona-toolkit-2.1.3-2.noarch
    Percona-Server-test-51-5.1.65-rel14.0.475.rhel6.x86_64
    Percona-Server-devel-51-5.1.65-rel14.0.475.rhel6.x86_64
    postfix-2.6.6-2.2.el6_1.x86_64
    Percona-Server-client-51-5.1.65-rel14.0.475.rhel6.x86_64
    percona-xtrabackup-test-2.0.2-461.rhel6.x86_64
    Percona-Server-51-debuginfo-5.1.65-rel14.0.475.rhel6.x86_64

rpm -qa | grep -iE 'mysql|percona|postfix'
    Percona-Server-shared-compat-5.5.27-rel28.1.296.rhel6.x86_64
    percona-xtrabackup-test-2.0.2-461.rhel6.x86_64
    Percona-Server-devel-55-5.5.27-rel28.1.296.rhel6.x86_64
    Percona-Server-shared-55-5.5.27-rel28.1.296.rhel6.x86_64
    percona-xtrabackup-2.0.2-461.rhel6.x86_64
    perl-DBD-MySQL-4.013-3.el6.x86_64
    Percona-Server-client-55-5.5.27-rel28.1.296.rhel6.x86_64
    percona-toolkit-2.1.3-2.noarch
    Percona-Server-test-55-5.5.27-rel28.1.296.rhel6.x86_64
    Percona-Server-55-debuginfo-5.5.27-rel28.1.296.rhel6.x86_64
    postfix-2.6.6-2.2.el6_1.x86_64
    postfix-debuginfo-2.6.6-2.2.el6_1.x86_64
    Percona-Server-server-55-5.5.27-rel28.1.296.rhel6.x86_64

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007f0ac78e9fb8 in main_arena () from /lib64/libc.so.6
(gdb) #0 0x00007f0ac78e9fb8 in main_arena () from /lib64/libc.so.6
#1 0x00007f0ac856b287 in EVP_CIPHER_CTX_cleanup () from /usr/lib64/libcrypto.so.10
#2 0x00007f0ac856bcf5 in EVP_CipherInit_ex () from /usr/lib64/libcrypto.so.10
#3 0x00007f0ac8875296 in tls1_change_cipher_state () from /usr/lib64/libssl.so.10
#4 0x00007f0ac886a88b in ssl3_connect () from /usr/lib64/libssl.so.10
#5 0x00007f0ac9c01827 in tls_bio (fd=13, timeout=300, TLScontext=0x7f0acb32c150, hsfunc=0x7f0ac887f460 <SSL_connect>, rfunc=0, wfunc=0, buf=0x0, num=0) at tls_bio_ops.c:266
#6 0x00007f0ac9c00465 in tls_client_start (props=0x7fff47a77040) at tls_client.c:903
#7 0x00007f0ac9bf9317 in smtp_start_tls (state=0x7f0acb32e570) at smtp_proto.c:746
#8 smtp_helo (state=0x7f0acb32e570) at smtp_proto.c:632
#9 0x00007f0ac9bf6081 in smtp_connect_remote (state=0x7f0acb32e570, nexthop=<value optimized out>, def_service=0x7f0ac9c34d87 "smtp") at smtp_connect.c:887
#10 0x00007f0ac9bf6907 in smtp_connect (state=0x7f0acb32e570) at smtp_connect.c:1041
#11 0x00007f0ac9bf5202 in deliver_message (client_stream=0x7f0acb32c310, service=0x7fff47a78f8a "smtp", argv=<value optimized out>) at smtp.c:854
#12 smtp_service (client_stream=0x7f0acb32c310, service=0x7fff47a78f8a "smtp", argv=<value optimized out>) at smtp.c:886
#13 0x00007f0ac9bff827 in single_server_wakeup (fd=<value optimized out>) at single_server.c:262
#14 0x00007f0ac9c260b7 in event_loop (delay=<value optimized out>) at events.c:1086
#15 0x00007f0ac9bff60a in single_server_main (argc=<value optimized out>, argv=<value optimized out>, service=0x7f0ac9bf5160 <smtp_service>) at single_server.c:732
#16 ...

Read more...

The attachment contains:

1. Relevant postfix config which I changed from default.

2. Full backtrace on both 5.1 and 5.5

3. mysqldump of postfix_alias table (it needs to be loaded into postfix database)

For the records, here is the ldd output of upstream

ldd /usr/lib64/libmysqlclient.so.16.0.0
        linux-vdso.so.1 => (0x00007fff2f941000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3e933d3000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f3e931ba000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3e92f35000)
        libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f3e92cda000)
        libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f3e92940000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f3e92729000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3e92396000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f3e92134000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f3e91ef1000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f3e91c12000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f3e91a0e000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f3e917e1000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3e915dd000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037e3400000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f3e913d2000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f3e911ce000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3e90fb4000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3e90d97000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3e90b77000)

From Percona-Server-shared-compat provided by us:

ldd ./usr/lib64/libmysqlclient.so.16.0.0
        linux-vdso.so.1 => (0x00007fffeb1ff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f16ad91a000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f16ad6e3000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f16ad4c9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f16ad245000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f16aceb2000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037e3400000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f16acc4f000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f16aca4b000)

From Percona-Server-shared-55:

ldd /usr/lib64/libmysqlclient.so.18.0.0
        linux-vdso.so.1 => (0x00007fff1adff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4db9973000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4db976f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4db94ea000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f4db92e2000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4db8f4f000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037e3400000)

So, this will need fixing as well.

libmysqlclient.so.18.0.0 on one of the distro installations (Arch) of percona-server:

ldd /usr/lib/libmysqlclient.so.18.0.0
        linux-vdso.so.1 (0x00007fffca5ff000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fe896030000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fe895dc6000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fe8959bc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe8957b8000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe89559c000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fe8952a1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fe894efa000)
        /usr/lib/ld-linux-x86-64.so.2 (0x00007fe89694e000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fe894667000)

For libmysqlclient of mysql on same distro:

ldd /usr/lib/libmysqlclient.so.18.0.0
        linux-vdso.so.1 (0x00007fff2edbe000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f9bfd1b8000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f9bfcf4e000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f9bfcb44000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f9bfc940000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f9bfc724000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f9bfc429000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f9bfc082000)
        /usr/lib/ld-linux-x86-64.so.2 (0x00007f9bfdad6000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f9bfb7ef000)

So, "libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0" may be the key missing piece in Percona-Server-* packages.

summary: Postfix crashes using shared dependency(libmysqlclient.so) provided by
- Percona Server shared library in RHEL 6.1
+ Percona Server-shared-compat / Percona-Server-shared in CentOS/RHEL 6.x
Alexey Kopytov (akopytov) wrote :

I'm not sure I understand what's the problem here. So Postfix crashes,
but I don't see any libmysqclient calls in the backtrace.

Does this mean our libmysqlclient.so somehow breaks TLS even if it's
just loaded but not really used?

I actually tested with libmysqlclient of upstream and it didn't crash. (also in google groups link someone did the same).

I presume that calls to mysqlclient are made in between and crash happens later.

Another thing, smtp didn't crash when smtp tls was not enabled in postfix config.

Also, I enabled slow query logging in mysql and this crash took place after the query since I saw the query in the log.

What makes this interesting is that, query to local mysqld itself doesn't make use of any ssl (or so I believe).

Another test that can be done is to build a srpm with rpmbuild and test with that libmysqlclient.

Barney Desmond (barneydesmond) wrote :

Hi there,

We've been following this issue at our company and believe we have a firm grasp on the problem here, so I'd like to make two notes.

1. This bug *appears* to be related to #1002164, I'm not sure if they should be linked in any way.

2. Our description is of the problem is published here, we believe it's accurate:
http://www.anchor.com.au/blog/2012/09/why-does-percona-cause-ssl-issues-in-postfix/

Alexey, the answer to your question appears to be "yes".

A direct technical summary is as follows:

 * We see the problem in /usr/libexec/postfix/smtp when SSL/TLS is attempted, it segfaults
 * ldd shows that it links to libcrypto.so.10 and libmysqlclient.so.16
 libmysqlclient.so.16 => /usr/lib64/libmysqlclient.so.16 (0x00007f586b3b2000)
 libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f586a91e000)
 * libmysqlclient embeds YaSSL, which provides four dummy functions:
    - CRYPTO_add_lock
    - CRYPTO_lock
    - CRYPTO_mem_ctrl
    - EVP_CIPHER_CTX_init
 * These functions are not used internally by libmysqlclient, nor are they “hidden” in any way
 * Those symbols are also exported by libcrypto, which actually implements them properly. Software like Postfix (and PHP, amongst others) expect to use libcrypto's functions
 * The symbols from libmysqlclient are “winning” over those from libcrypto
 * When Postfix tries to use SSL/TLS, it hits those broken functions and then segfaults

We then looked further into the packaging to see what could be done.

 * /usr/lib64/libmysqlclient.so.16 is provided by the package Percona-Server-shared-compat
 * Percona-Server-shared-compat is built directly from Mysql-shared-compat, thus the bug is upstream
 * The bug appears to have since been fixed in MySQL
 * Percona is built with a specific version of Mysql-shared-compat that has the buggy libmysqlclient

Therefore, we believe the correct approach to fix Percona is to target a version of Mysql-shared-compat that doesn't contain the buggy libmysqlclient.so.16 library.

----

We hope this information is useful, we'd be happy to answer further questions if it's helpful.

System details:

--
root@lily:~# rpm -qa | grep Percona
Percona-Server-shared-55-5.5.27-rel28.1.296.rhel6.x86_64
Percona-Server-server-55-5.5.27-rel28.1.296.rhel6.x86_64
Percona-Server-shared-compat-5.5.27-rel28.1.296.rhel6.x86_64
Percona-Server-client-55-5.5.27-rel28.1.296.rhel6.x86_64

--
root@lily:~# cat /etc/redhat-release
CentOS release 6.3 (Final)

--
root@lily:~# uname -a
Linux lily.example.com 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 23:54:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

----
The problem has also be observed on a CentOS 5 server:

--
root@rock:~# rpm -qa | grep Percona
Percona-Server-client-55-5.5.27-rel28.1.296.rhel5
Percona-XtraDB-Cluster-devel-5.5.27-23.6.356.rhel5
Percona-Server-shared-compat-5.5.27-rel28.1.296.rhel5
Percona-Server-shared-55-5.5.27-rel28.1.296.rhel5
Percona-Server-server-55-5.5.27-rel28.1.296.rhel5

--
root@rock:~# cat /etc/redhat-release
CentOS release 5.8 (Final)

--
root@rock:~# uname -a
Linux rock.example.com 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Barney Desmond (barneydesmond) wrote :

I should also note that the issue appears to be known at MySQL, though it's not clear if the patch applies to MySQL 5.5 as well:
http://bugs.mysql.com/bug.php?id=65055

The fix is to avoid building crypto.cpp in mysql/extra/yassl/taocrypt/src/Makefile.am

So long as the upstream compat libraries were built correctly (without crypto.cpp), Percona can package them and the problems with Postfix/PHP/etc should go away.

Barney - thanks for your detailed analysis.

It seems that bug 1002164 is duplicate, marking it as such and copying its triage.

Barney,

On 18.09.12 11:53, Barney Desmond wrote:
> Hi there,
>
> We've been following this issue at our company and believe we have a
> firm grasp on the problem here, so I'd like to make two notes.
>
>
> 1. This bug *appears* to be related to #1002164, I'm not sure if they should be linked in any way.
>
> 2. Our description is of the problem is published here, we believe it's accurate:
> http://www.anchor.com.au/blog/2012/09/why-does-percona-cause-ssl-issues-in-postfix/
>
> Alexey, the answer to your question appears to be "yes".

Thank you very much for confirming and the detailed summary. The problem
looks clear now:

- the root cause does seem to be the YaSSL symbol conflicts with
libcrypto, which is bug #1002164.

- the same problem still exist upstream (and has been reported as
http://bugs.mysql.com/bug.php?id=65055)

- precompiled upstream packages are built against OpenSSL rather than
bundled YaSSL, so they don't exhibit this problem. IIRC only Windows
upstream packages are built with bundled YaSSL.

- our RPM packages are built with bundled YaSSL, while .debs are built
against OpenSSL.

So in addition to fixing bug #1002164 (and the upstream bug), we have to
make sure the YaSSL option in our RPM packages is intended. We might
have a packaging bug here as well.

Alexey Kopytov (akopytov) wrote :

In case we have a packaging issue (see my previous comment), we should either not mark this bug as a duplicate of bug #1002164, or report the packaging issue separately.

Sebastian (sebastian-seo) wrote :

Is this issue going to be solve or it's not possible to run Postfix (TLS) with Percona MySQL server on the same machine at the moment?

Alexey Kopytov (akopytov) wrote :

Sebastian,

The issue is going to be resolved with next Percona Server releases. At
the moment, the only workaround that we know is referenced from the
original report.

Sebastian (sebastian-seo) wrote :

Alexey,

Thanks for your reply.

Is there any date set already for the new release?

Regards
Sebastian

Ignacio Nin (ignacio-nin) wrote :

Building without --with yassl seems avoids including these functions. With debuginfo installed from:

http://www.percona.com/redir/downloads/Percona-Server-5.1/Percona-Server-5.1.65-14.0/RPM/rhel6/x86_64/Percona-Server-51-debuginfo-5.1.65-rel14.0.475.rhel6.x86_64.rpm:

# nm /usr/lib/debug/usr/lib64/libmysqlclient.so.debug | fgrep ' T ' | fgrep CRYPTO
00000000000bfef0 T CRYPTO_add_lock
00000000000bfee0 T CRYPTO_lock
00000000000bff10 T CRYPTO_mem_ctrl

with http://www.percona.com/redir/downloads/TESTING/Percona-Server-51/Percona-Server-5.1.65-rel14.0/5.1-bug1028240/482/RPM/rhel6/x86_64/Percona-Server-51-debuginfo-5.1.65-rel14.0.482.rhel6.x86_64.rpm:

# nm /usr/lib/debug/usr/lib64/libmysqlclient.so.debug | fgrep ' T ' | fgrep CRYPTO
is empty.

Please try the original issue with these packages. They can be installed from the percona-testing repository as well.

I have servers running both 5.1 and 5.5 libraries.

I'm still seeing this issue with Percona Server 5.5.27-29.0.

The /usr/lib64/libmysqlclient.so.16.0.0 from Percona-Server-shared-51-5.1.65-rel14.0.482 works though.

I have not tried the 51-shared-compat version as I don't use that package.

Kristian Kostecky (kris-gq) wrote :

I can confirm what Andrew Grim is claiming. I am using 5.5.27-29.0 and percona is still segfaulting.

Alexey Kopytov (akopytov) wrote :

We have to re-verify this against 5.5.27-29.0

Bart Verwilst (verwilst) wrote :

Confirmed NOT to work with 5.5.27-29.0, Postfix still segfaults.

@17,

The symbols mentioned there are still in

libmysqlclient_r.so.15
libmysqlclient_r.so.15.0.0
libmysqlclient_r.so.16
libmysqlclient_r.so.16.0.0
libmysqlclient.so.15
libmysqlclient.so.15.0.0
libmysqlclient.so.16
libmysqlclient.so.16.0.0

ldd `which postfix` | grep mysqlclient
        libmysqlclient.so.16 => /usr/lib64/libmysqlclient.so.16 (0x00007fe07eaba000)

nm -D /usr/lib64/libmysqlclient.so.16.0.0 | grep CRYPTO_
00000000000bf3e0 T CRYPTO_add_lock
00000000000bf3d0 T CRYPTO_lock
00000000000bf400 T CRYPTO_mem_ctrl

rpm -qa | grep shared
Percona-Server-shared-compat-5.5.27-rel29.0.315.rhel6.x86_64
Percona-Server-shared-55-5.5.27-rel29.0.315.rhel6.x86_64

nm -D /usr/lib64/libmysqlclient.so.16.0.0 | grep CRYPTO_

 is empty for the libmysqlclient.so.16.0.0 for the one in mysql-libs-5.1.65

This bug is present in both upstream versions of shared-compat (5.1 and 5.5):

From MySQL-shared-compat-5.5.28-1.rhel5.x86_64.rpm:

    for x in *;do nm -D $x 2>/dev/null | grep -q CRYPTO_ && echo $x;done
    libmysqlclient.so.15.0.0
    libmysqlclient.so.16.0.0
    libmysqlclient_r.so.15.0.0
    libmysqlclient_r.so.16.0.0

From MySQL-shared-compat-5.1.65-1.rhel5.x86_64.rpm:

    for x in *;do nm -D $x 2>/dev/null | grep -q CRYPTO_ && echo $x;done
    libmysqlclient.so.15.0.0
    libmysqlclient_r.so.15.0.0

Now, the reason why it doesn't crash with mysql-libs is because the only
version of mysql-libs present in rpm repos is mysql-libs-5.1.65 which
doesn't have this issue.

Percona-Server-shared-compat is derived from upstream one, hence it has the same issues.

The 'workaround' is to use Percona-Server-shared-51, however, that is not
possible since Percona-Server-shared-55 and Percona-Server-shared-51
conflict.

Verified the latest release -- 5.5.28-29.1 -- https://launchpad.net/percona-server/+milestone/5.5.28-29.1

It can be used with postfix since the libmysqlclient.so.16.0.0 provided with that does not have any conflicting symbols. (We are providing our own libmysqlclient.so.16.0.0 in the shared-compat for time being than the upstream one)

for x in *;do nm -D $x 2>/dev/null | =grep -q CRYPTO_ && echo $x;done
libmysqlclient.so.15.0.0
libmysqlclient_r.so.15.0.0

However, this shouldn't affect since postfix links against libmysqlclient.so.16.0.0.

Bart Verwilst (verwilst) wrote :

5.5.28-29.1 + postfix works for me!

Alexey Kopytov (akopytov) wrote :

Setting to Fix Released and re-targeting to 5.5.28-29.1, as the fix has been confirmed to work in that release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.