Bug 1213440
| Summary: | crash when linking libtspi and libmysqlclient | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nikos Mavrogiannopoulos <nmavrogi> |
| Component: | mariadb | Assignee: | Jakub Dorňák <jdornak> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | databases-maint, hhorak, nmavrogi |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-24 17:42:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
If I don't miss anything, I don't see anything mariadb may do differently, it must be fixed in trousers package, right? 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. (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. (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. (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? can you be more specific? I don't understand what are you asking for. a code example how you mean it would help. 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. 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. (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. |
[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.