RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1213440 - crash when linking libtspi and libmysqlclient
Summary: crash when linking libtspi and libmysqlclient
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mariadb
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Dorňák
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-20 14:48 UTC by Nikos Mavrogiannopoulos
Modified: 2015-11-24 17:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-24 17:42:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1071171 0 urgent CLOSED crash when linking libtspi and libmysqlclient 2021-02-22 00:41:40 UTC

Description Nikos Mavrogiannopoulos 2015-04-20 14:48:48 UTC 
[This is a copy of #1071685 and it affects RHEL as well]

A trivial program that links against both libmysqlclient and libtspi will crash with a segfault.

Version-Release number of selected component (if applicable):
trousers-devel-0.3.11.2-3.el7
mariadb-devel-5.5.35-2.el7

How reproducible:
$ cat test.c
int main ()
{
  return 0;
}

$ gcc test.c -o test  -L/usr/lib64/mysql -lmysqlclient -ltspi 

$ ./test
Segmentation fault (core dumped)

backgrace in valgrind:

==3836== Invalid read of size 4
==3836==    at 0x3942009FE0: pthread_mutex_lock (pthread_mutex_lock.c:66)
==3836==    by 0x31CFE22BC3: host_table_final (hosttable.c:54)
==3836==    by 0x394140F8E9: _dl_fini (dl-fini.c:252)
==3836==    by 0x39418394C8: __run_exit_handlers (exit.c:82)
==3836==    by 0x3941839514: exit (exit.c:104)
==3836==    by 0x3941821D6B: (below main) (libc-start.c:319)
==3836==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==3836== 
==3836== 
==3836== Process terminating with default action of signal 11 (SIGSEGV)
==3836==  Access not within mapped region at address 0x18
==3836==    at 0x3942009FE0: pthread_mutex_lock (pthread_mutex_lock.c:66)
==3836==    by 0x31CFE22BC3: host_table_final (hosttable.c:54)
==3836==    by 0x394140F8E9: _dl_fini (dl-fini.c:252)
==3836==    by 0x39418394C8: __run_exit_handlers (exit.c:82)
==3836==    by 0x3941839514: exit (exit.c:104)
==3836==    by 0x3941821D6B: (below main) (libc-start.c:319)


Actual results:
The program segfaults.

Expected results:
The program should exit normally.


This affects linking gnutls (which depends on libtspi) with mariadb libraries.
Comment 2 Honza Horak 2015-04-20 15:31:33 UTC 
If I don't miss anything, I don't see anything mariadb may do differently, it must be fixed in trousers package, right?
Comment 3 Nikos Mavrogiannopoulos 2015-04-21 08:12:17 UTC 
No, the problem is in mariadb as well as trousers. Both use constructors which are not marked as static. If either of them is solved the problem is solved, but the problem is in both packages.
Comment 4 Nikos Mavrogiannopoulos 2015-04-21 08:13:49 UTC 
(In reply to Nikos Mavrogiannopoulos from comment #3)
> No, the problem is in mariadb as well as trousers. Both use constructors
> which are not marked as static.

I should add here, with a very common name as "my_init", which is a recipe for collisions like the one we see here.
Comment 5 Honza Horak 2015-04-21 12:07:32 UTC 
(In reply to Nikos Mavrogiannopoulos from comment #4)
> (In reply to Nikos Mavrogiannopoulos from comment #3)
> > No, the problem is in mariadb as well as trousers. Both use constructors
> > which are not marked as static.
> 
> I should add here, with a very common name as "my_init", which is a recipe
> for collisions like the one we see here.

my_init is part of the API, it cannot be just removed from exported symbols or made static:
http://dev.mysql.com/doc/refman/5.5/en/my-init.html

What is more, if the upstream decides to rename that function, the libmysqlclient would become incompatible, so there would have to be really big demand to do it.

Since it is not exported in libtspi.so, that's the place we need to look at a potential fix.
Comment 6 Nikos Mavrogiannopoulos 2015-04-23 13:18:18 UTC 
(In reply to Honza Horak from comment #5)
> (In reply to Nikos Mavrogiannopoulos from comment #4)
> > (In reply to Nikos Mavrogiannopoulos from comment #3)
> > > No, the problem is in mariadb as well as trousers. Both use constructors
> > > which are not marked as static.
> > 
> > I should add here, with a very common name as "my_init", which is a recipe
> > for collisions like the one we see here.
> 
> my_init is part of the API, it cannot be just removed from exported symbols
> or made static:
> http://dev.mysql.com/doc/refman/5.5/en/my-init.html
> 
> What is more, if the upstream decides to rename that function, the
> libmysqlclient would become incompatible, so there would have to be really
> big demand to do it.

Wouldn't removing the constructor attribute from the my_init() and having another static function, which calls the first, with that attribute solve that issue too?
Comment 7 Honza Horak 2015-04-23 13:22:29 UTC 
can you be more specific? I don't understand what are you asking for. a code example how you mean it would help.
Comment 8 Nikos Mavrogiannopoulos 2015-04-23 13:58:59 UTC 
Disregard. It checked the source code and my_init() isn't a constructor. There is very little it can be done in mariadb for this issue.
Comment 9 Honza Horak 2015-04-24 05:20:39 UTC 
Well, maybe changing the name to mysql_my_init and defining:

  #define my_init mysql_my_init

in the header might help, but I don't know trousers enough to tell if some source may include both header files (from mariadb and trousers) at the same time and what would it mean.. Might be worth further investigating and consulting with upstream.
Comment 10 Honza Horak 2015-11-24 17:42:06 UTC 
(In reply to Honza Horak from comment #9)
> Well, maybe changing the name to mysql_my_init and defining:
> 
>   #define my_init mysql_my_init

This won't work because we'd loose the my_init in library, so it would mean ABI change in practice, which is something not acceptable. I'm closing this bug for now, since there is nothing I see mariadb could do differently.
Note You need to log in before you can comment on or make changes to this bug.