Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.1(EOL)
-
None
Description
http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/4697/steps/test_5/logs/stdio
plugins.show_all_plugins w1 [ fail ]
|
Test ended at 2015-08-21 22:11:44
|
|
|
CURRENT_TEST: plugins.show_all_plugins
|
mysqltest got signal 6
|
read_command_buf (0x13e1ce0):
|
conn->name (0x37604e8):
|
conn->cur_query (0x3850878): select variable_value > 10 from information_schema.global_status where variable_name like '%libraries%'
|
Attempting backtrace...
|
stack_bottom = 0x0 thread_stack 0x48000
|
mysys/stacktrace.c:247(my_print_stacktrace)[0x55778b]
|
bits/stdio2.h:99(dump_backtrace)[0x53bce9]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fd7dbdb7cb0]
|
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fd7da7b3445]
|
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fd7da7b6bab]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x73e2e)[0x7fd7da7f0e2e]
|
/lib/x86_64-linux-gnu/libc.so.6(__libc_fatal+0x1e)[0x7fd7da7f0efe]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10491)[0x7fd7dbdb8491]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x1057c)[0x7fd7dbdb857c]
|
/lib/x86_64-linux-gnu/libpthread.so.0(__pthread_unwind+0x40)[0x7fd7dbdb66a0]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8ff5)[0x7fd7dbdb0ff5]
|
client/mysqltest.cc:907(connection_thread)[0x53be3f]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fd7dbdafe9a]
|
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd7da86f4bd]
|
Writing a core file...
|
|
|
- saving '/mnt/buildbot/build/mariadb-10.1.6/mysql-test/var/1/log/plugins.show_all_plugins/' to '/mnt/buildbot/build/mariadb-10.1.6/mysql-test/var/log/plugins.show_all_plugins/'
|
|
|
Retrying test plugins.show_all_plugins, attempt(2/3)...
|
|
|
worker[1] > Restart - not started
|
libgcc_s.so.1 must be installed for pthread_cancel to work
|
I can reproduce it on my local machine if I build the server the same way buildbot does (including the message about libgcc_s.so.1 which I don't understand, as I have the library).
Attachments
Issue Links
- relates to
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- links to
Activity
Just for the reference, what I've found so far.
The culprit here is Mroonga. The test doesn't install it, but it dlopen()'s ha_mroonga.so and that's enough. In --embedded test run this seem to somehow corrupt internal dynamic linker data sructures (?) and later, it thinks that libgcc_s.so.1 failed to load.
See also:
http://stackoverflow.com/questions/6591389/dlopen-works-second-time-on-bad-shared-library-on-ubuntu-11-04-does-the-right-t
https://sourceware.org/bugzilla/show_bug.cgi?id=14577
Micro test that triggers similar problem:
#include <stdio.h>
|
#include <dlfcn.h>
|
|
|
#define LIB "var/plugins/ha_innodb.so"
|
|
|
int main(void)
|
{
|
void *handle= dlopen(LIB, RTLD_NOW);
|
fprintf(stderr, "handle= %p, error= %s\n", handle, dlerror());
|
handle= dlopen(LIB, RTLD_NOW);
|
fprintf(stderr, "handle= %p, error= %s\n", handle, dlerror());
|
return 0;
|
}
|
I also managed to crash debug build with the following test:
mtr --embedded
|
--error 1126
|
INSTALL SONAME 'ha_mroonga';
|
--error 1126
|
INSTALL SONAME 'ha_mroonga';
|
https://github.com/MariaDB/server/commit/ff03b96b0605ed054849bde343b40bde581d035d
svoj,
Please push the test change for now.
I don't know how much hope there is for the dlopen bug to be fixed (reported 3 years ago, modified 1+ year ago?), I'd vote for looking into possible workarounds on our side.
Disabled plugins.show_all_plugins in embedded mode until dynamic linker is fixed.
According to the cross-reference report, it started happening around here: http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/4569