Details
Minor
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).
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- links to
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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';
Sergei Golubchik, please review patch for this bug.
https://github.com/MariaDB/server/commit/ff03b96b0605ed054849bde343b40bde581d035d
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