Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
10.0(EOL)
-
10.0.20
Description
The problem was originally found with this tree: https://github.com/Buggynours/MariaDB, but it's also reproducible with the main MariaDB tree git@github.com:MariaDB/server.git with the 10.0 branch.
The 5.5 branch in git@github.com:MariaDB/server.git works without problems.
I configure MariaDB as follows:
cmake . -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/mariadb-10.0 -DWITH_CONNECT_STORAGE_ENGINE=1
then do make && make install followed by mysql_install_db.
Now if I run mysqld and try to connect using a non-privileged user, mysqld crashes on assert with the following output:
bar@lxOtto:/opt/maria-git/MariaDB/sql> ./mysqld
|
150603 5:48:38 [Note] CONNECT: Version 1.03.0007 April 30, 2015
|
150603 5:48:38 [Note] InnoDB: Using mutexes to ref count buffer pool pages
|
2015-06-03 05:48:38 3fffce1a730 InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
|
2015-06-03 05:48:38 3fffce1a730 InnoDB: !!!!!!!! UNIV_SYNC_DEBUG switched on !!!!!!!!!
|
150603 5:48:38 [Note] InnoDB: The InnoDB memory heap is disabled
|
150603 5:48:38 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
|
150603 5:48:38 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
|
150603 5:48:38 [Note] InnoDB: Compressed tables use zlib 1.2.3
|
150603 5:48:38 [Note] InnoDB: Not using CPU crc32 instructions
|
150603 5:48:38 [Note] InnoDB: Initializing buffer pool, size = 128.0M
|
150603 5:48:38 [Note] InnoDB: Completed initialization of buffer pool
|
150603 5:48:38 [Note] InnoDB: Highest supported file format is Barracuda.
|
150603 5:48:39 [Note] InnoDB: 128 rollback segment(s) are active.
|
150603 5:48:39 [Note] InnoDB: Waiting for purge to start
|
150603 5:48:39 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-72.0 started; log sequence number 1616857
|
150603 5:48:39 [Note] Server socket created on IP: '::'.
|
150603 5:48:39 [Note] Event Scheduler: Loaded 0 events
|
150603 5:48:39 [Note] ./mysqld: ready for connections.
|
Version: '10.0.17-MariaDB-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
|
mysqld: /opt/maria-git/MariaDB/sql/sql_error.cc:407: void Diagnostics_area::set_eof_status(THD*): Assertion `! is_set()' failed.
|
150603 5:48:41 [ERROR] mysqld got signal 6 ;
|
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 http://kb.askmonty.org/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.0.17-MariaDB-debug
|
key_buffer_size=134217728
|
read_buffer_size=131072
|
max_used_connections=1
|
max_threads=153
|
thread_count=1
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467212 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x0x8c4d92d0
|
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 = 0x3ffec0daf10 thread_stack 0x48000
|
addr2line: './mysqld': No such file
|
./mysqld(my_print_stacktrace+0x36)[0x80dcc42e]
|
./mysqld(handle_fatal_signal+0x3fe)[0x8053cc96]
|
[0x3ffec0d9f7c]
|
/lib64/libc.so.6(gsignal+0x40)[0x3fffce574f0]
|
/lib64/libc.so.6(abort+0x118)[0x3fffce589f8]
|
/lib64/libc.so.6(+0x3267e)[0x3fffce4f67e]
|
/lib64/libc.so.6(+0x3270c)[0x3fffce4f70c]
|
./mysqld(_ZN16Diagnostics_area14set_eof_statusEP3THD+0x72)[0x802a6d5a]
|
./mysqld(_Z6my_eofP3THD+0x46)[0x80207eae]
|
./mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x2ea)[0x8036deaa]
|
./mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x136a)[0x802d2582]
|
./mysqld(_Z10do_commandP3THD+0x3e2)[0x802d0ed2]
|
./mysqld(_Z24do_handle_one_connectionP3THD+0x2a4)[0x80430bf4]
|
./mysqld(handle_one_connection+0x44)[0x80430814]
|
/lib64/libpthread.so.0(+0x8524)[0x3fffd1e8524]
|
/lib64/libc.so.6(+0xe7f4a)[0x3fffcf04f4a]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x3ffac0051d8):
|
Connection ID (thread ID): 2
|
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
|
|
|
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.
|
If the first connection is done by "mysql --user=root test", then it works fine, so do all further non-privileged connections.
If I do the first connection with a non-privileged user using "mysql -A test", it works fine, however the next connection "mysql test" crashes again.