Adding printf() on the constructor and destructor reveals that when linking with both mysqlclient and tspi, only the destructor of tspi is called but not the constructor (and thus the crash).

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This package should be rebased to the current release to fix this and several other problems.

any news about this one?

It still occurs on 7.1.

Since the release of Red Hat Enterprise Linux 7.1 this issue is more serious. Now gnutls links against libtspi and any application using gnutls is potentially affected. One real world scenario when this issue happens is zabbix server. I tried with packages from EPEL repo, versions below the trace (note this test system is running CentOS 7.1, not RHEL):

[root@cfzabbix zabbix]# su zabbixsrv -s /bin/bash -c 'valgrind /usr/sbin/zabbix_server_mysql'
==28745== Memcheck, a memory error detector
==28745== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28745== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==28745== Command: /usr/sbin/zabbix_server_mysql
==28745==
==28745== Invalid read of size 4
==28745==    at 0x7D56C00: pthread_mutex_lock (pthread_mutex_lock.c:50)
==28745==    by 0xB6B1BB3: host_table_final (hosttable.c:54)
==28745==    by 0x400FB59: _dl_fini (dl-fini.c:253)
==28745==    by 0x79C4E48: __run_exit_handlers (exit.c:77)
==28745==    by 0x79C4E94: exit (exit.c:99)
==28745==    by 0x46C0B3: daemon_start (in /usr/sbin/zabbix_server_mysql)
==28745==    by 0x79ADAF4: (below main) (libc-start.c:274)
==28745==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==28745==    
==28745==    
==28745== Process terminating with default action of signal 11 (SIGSEGV)
==28745==  Access not within mapped region at address 0x18
==28745==    at 0x7D56C00: pthread_mutex_lock (pthread_mutex_lock.c:50)
==28745==    by 0xB6B1BB3: host_table_final (hosttable.c:54)
==28745==    by 0x400FB59: _dl_fini (dl-fini.c:253)
==28745==    by 0x79C4E48: __run_exit_handlers (exit.c:77)
==28745==    by 0x79C4E94: exit (exit.c:99)
==28745==    by 0x46C0B3: daemon_start (in /usr/sbin/zabbix_server_mysql)
==28745==    by 0x79ADAF4: (below main) (libc-start.c:274)
==28745==  If you believe this happened as a result of a stack
==28745==  overflow in your program's main thread (unlikely but
==28745==  possible), you can try to increase the size of the
==28745==  main thread stack using the --main-stacksize= flag.
==28745==  The main thread stack size used in this run was 8388608.

[root@cfzabbix ~]# rpm -qa | grep 'zabbix\|gnutls\|trousers'
zabbix22-2.2.7-1.el7.x86_64
gnutls-3.3.8-12.el7.centos.x86_64
zabbix22-dbfiles-mysql-2.2.7-1.el7.noarch
zabbix22-web-mysql-2.2.7-1.el7.noarch
zabbix22-agent-2.2.7-1.el7.x86_64
trousers-0.3.11.2-3.el7.x86_64
zabbix22-web-2.2.7-1.el7.noarch
zabbix22-server-2.2.7-1.el7.noarch
trousers-debuginfo-0.3.11.2-3.el7.x86_64
zabbix22-server-mysql-2.2.7-1.el7.x86_64
gnutls-debuginfo-3.3.8-12.el7.centos.x86_64

I recompiled gnutls package from the original SRPM and edited the spec file to pass the --without-tpm option to %configure. This way gnutls doesn't link to libtspi anymore and zabbix server can start and operate without problems. This is just a workaround however and not a proper solution.

Then I noticed this bug is a copy of bug #1069079 against Fedora. I tried the proposed patch (now included in both Fedora and trousers upstream) applying it to the original SRPM and recompiled, Zabbix works like a charm.

Given gnutls is fairly common and with the latest update Red Hat enabled tpm support in it the chances of collisions are increased and affects also program not directly linking libtspi as in the case of Zabbix server

[root@cfzabbix etc]# objdump -p /usr/sbin/zabbix_server_mysql  | grep NEEDED
  NEEDED               libmysqlclient.so.18
  NEEDED               libiksemel.so.3
  NEEDED               libxml2.so.2
  NEEDED               libodbc.so.2
  NEEDED               libnetsnmp.so.31
  NEEDED               libssl.so.10
  NEEDED               libcrypto.so.10
  NEEDED               libm.so.6
  NEEDED               libssh2.so.1
  NEEDED               libOpenIPMI.so.0
  NEEDED               libOpenIPMIposix.so.0
  NEEDED               libldap-2.4.so.2
  NEEDED               liblber-2.4.so.2
  NEEDED               libcurl.so.4
  NEEDED               libdl.so.2
  NEEDED               libresolv.so.2
  NEEDED               libc.so.6

which links to /lib64/libiksemel.so.3 which links to gnutls which links to libtspi.

hi:
    will redhat release new trousers to fix the problem? to run zabbix now I just downgrade gnutls. but I hope this can be fixed.

I'm the Zabbix maintainer and I'd love to know what your plans are.

There is already a patch http://sourceforge.net/p/trousers/bugs/172/ - so what do you guys still need to fix the package?

when will RedHat release a new package with the patch ?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2104.html