main.events_2 failed in buildbot (server crash)

main.events_2                            w2 [ fail ]

        Test ended at 2017-07-06 22:56:46

CURRENT_TEST: main.events_2

mysqltest: In included file "/usr/local/mariadb-10.2.7-linux-i686/mysql-test/include/wait_condition.inc": 

included from /usr/local/mariadb-10.2.7-linux-i686/mysql-test/t/events_2.test at line 77:

At line 43: query 'let $success= `$wait_condition`' failed with wrong errno 2013: 'Lost connection to MySQL server during query', instead of 0...

The result from queries just before the failure was:

< snip >

"ENABLE the scheduler and get a lock"

set global event_scheduler=on;

select get_lock("test_lock2", 20);

get_lock("test_lock2", 20)

1

"Create an event which tries to acquire a mutex. The event locks on the mutex"

create event закачка on schedule every 10 hour do select get_lock("test_lock2", 20);

"Should have only 2 processes: the scheduler and the locked event"

select /*2*/ user, host, db, command, state, info

from information_schema.processlist

where (info like "select get_lock%" OR user='event_scheduler')

order by info;

user	host	db	command	state	info

event_scheduler	localhost	NULL	Daemon	Waiting for next activation	NULL

root	localhost	events_test	Connect	User lock	select get_lock("test_lock2", 20)

"Release the mutex, the event worker should finish."

select release_lock("test_lock2");

release_lock("test_lock2")

1

drop event закачка;

More results from queries before failure can be found in /usr/local/mariadb-10.2.7-linux-i686/mysql-test/var/2/log/events_2.log

Server [mysqld.1 - pid: 17284, winpid: 17284, exit: 256] failed during test run

Server log from this test:

----------SERVER LOG START-----------

2017-07-06 22:56:44 2955328320 [Note] Event Scheduler: scheduler thread started with id 32

170706 22:56:45 [ERROR] mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed, 

something is definitely wrong and this may fail.

Server version: 10.2.7-MariaDB-log

key_buffer_size=1048576

read_buffer_size=131072

max_used_connections=2

max_threads=153

thread_count=5

It is possible that mysqld could use up to 

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 61819 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0xb0100508

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

stack_bottom = 0xb02ff2cc thread_stack 0x49000

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(my_print_stacktrace+0x2d)[0xb72340fd]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(handle_fatal_signal+0x344)[0xb6c20a64]

[0xb6767400]

/lib/i386-linux-gnu/libc.so.6(+0x83c96)[0xb649dc96]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z23fill_schema_processlistP3THDP10TABLE_LISTP4Item+0x258)[0xb6adeb48]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x250)[0xb6ae8dc0]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_ZN4JOIN10exec_innerEv+0x7e0)[0xb6acd3c0]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_ZN4JOIN4execEv+0x39)[0xb6acd909]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x101)[0xb6acda41]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x293)[0xb6ace643]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(+0x2dfbf8)[0xb6a69bf8]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z21mysql_execute_commandP3THD+0x79f9)[0xb6a77e89]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x372)[0xb6a7cb72]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x3525)[0xb6a81265]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z10do_commandP3THD+0x1b0)[0xb6a81cf0]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1ee)[0xb6b5185e]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(handle_one_connection+0x49)[0xb6b51989]

/usr/local/mariadb-10.2.7-linux-i686/bin/mysqld(+0xa5f09d)[0xb71e909d]

/lib/i386-linux-gnu/libpthread.so.0(+0x6f70)[0xb6700f70]

/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6506d7e]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0xb010c9b8): select count(*) = 0 from information_schema.processlist where info='select get_lock("test_lock2", 20)'

Connection ID (thread ID): 31

Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains

information that should help you find out what is causing the crash.

Writing a core file

----------SERVER LOG END-------------