Hi,
Could you please also provide the data dump for the tables involved in the query or, if it is impossible, at least table structures?
If you can provide the dump, but it's too big or contains data you don't want to publish, you can upload it to ftp.askmonty.org:/private.
Thank you.
Hi Elena,
Thank you for the prompt reply. I have uploaded the dump at the private ftp area, the filename is dump.sql.xz (please don't make the data public).
Thank you.
Hi Vasilis,
Thank you.
Could you please also attach your cnf file? (or output of "SHOW VARIABLES" if you so prefer)
I have not got the crash so far with the provided data and query, so there must be something else that's also important.
Here it is.
[mysql]
|
# CLIENT #
|
port = 3306
|
socket = /var/run/mysqld/mysqld.sock
|
character-sets-dir = /usr/share/mysql/charsets
|
default-character-set = utf8
|
|
|
[mysqld]
|
# GENERAL #
|
user = mysql
|
port = 3306
|
character-set-server = utf8
|
default-storage-engine = InnoDB
|
socket = /var/run/mysqld/mysqld.sock
|
pid-file = /var/run/mysqld/mysqld.pid
|
basedir = /usr
|
skip_external_locking = 1
|
|
|
# MyISAM #
|
key_buffer_size = 24M
|
myisam-recover = FORCE,BACKUP
|
|
|
# SAFETY #
|
skip-networking
|
max_allowed_packet = 32M
|
max_connect_errors = 1000000
|
#skip_name_resolve
|
sql-mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
|
sysdate-is-now = 1
|
innodb = FORCE
|
innodb_strict_mode = 1
|
|
|
# DATA STORAGE #
|
datadir = /var/lib/mysql/
|
|
|
# CACHES AND LIMITS #
|
tmpdir = /tmp/
|
tmp_table_size = 64M
|
max_heap_table_size = 64M
|
query_cache_size = 12M
|
max_connections = 50
|
thread_cache_size = 30
|
open_files_limit = 65535
|
table_definition_cache = 4096
|
table_open_cache = 4096
|
group_concat_max_len = 16M
|
|
|
# INNODB #
|
innodb_flush_method = O_DIRECT
|
innodb_log_files_in_group = 2
|
innodb_log_file_size = 64M
|
innodb_flush_log_at_trx_commit = 2
|
innodb_file_per_table = 1
|
innodb_buffer_pool_size = 192M
|
innodb_additional_mem_pool_size = 16M
|
innodb_data_file_path = ibdata1:50M:autoextend:max:200M
|
innodb_log_buffer_size = 16M
|
innodb_file_per_table = 1
|
innodb_file_format = barracuda
|
innodb_fast_shutdown = 0
|
|
|
# LOGGING #
|
log_queries_not_using_indexes = 1
|
slow_query_log = 1
|
slow_query_log_file = /var/log/mysql/mysql-slow.log
|
log_error = /var/log/mysql/mysql.err
|
log_slow_verbosity = query_plan
|
Are you sure you can't reproduce this? This happened twice for me with the same query, once with 5.5.35 in Windows (32-bit) and once with 5.5.35 in my Linux box (64-bit).
Also confirmed the issue with our Debian 7 Linux servers at work, using 5.5.35 from your repositories. mysqld crashed, log:
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 [ERROR] mysqld got signal 11 ;
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: This could be because you hit a bug. It is also possible that this binary
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: or one of the libraries it was linked against is corrupt, improperly built,
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: To report this bug, see http://kb.askmonty.org/en/reporting-bugs
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: We will try our best to scrape up some info that will hopefully help
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: diagnose the problem, but since we have already crashed,
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: something is definitely wrong and this may fail.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Server version: 5.5.35-MariaDB-1~wheezy-log
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: key_buffer_size=8388608
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: read_buffer_size=131072
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: max_used_connections=1
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: max_threads=102
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: thread_count=1
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: It is possible that mysqld could use up to
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231268 K bytes of memory
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Hope that's ok; if not, decrease some variables in the equation.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Thread pointer: 0x0x927fd000
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Attempting backtrace. You can use the following information to find out
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: where mysqld died. If you see no messages after this, something went
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: terribly wrong...
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: stack_bottom = 0xb65b230c thread_stack 0x48000
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2d)[0xb7315f9d]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x478)[0xb6f0ff28]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: [0xb6b5a400]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_ZN10Item_field10fix_fieldsEP3THDPP4Item+0x4b3)[0xb6f31963]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_ZN9Item_func10fix_fieldsEP3THDPP4Item+0x1c8)[0xb6f62268]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z11setup_condsP3THDP10TABLE_LISTR4ListIS1_EPP4Item+0x1fe)[0xb6d82bae]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(+0x28a769)[0xb6e03769]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_ZN18st_select_lex_unit7prepareEP3THDP13select_resultm+0x8f3)[0xb6e509d3]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z21mysql_derived_prepareP3THDP3LEXP10TABLE_LIST+0x233)[0xb6da2573]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0x1b0)[0xb6da3560]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_ZN10TABLE_LIST14handle_derivedEP3LEXj+0x76)[0xb6e68ea6]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_ZN13st_select_lex14handle_derivedEP3LEXj+0x4a)[0xb6db8b4a]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(+0x28a4c5)[0xb6e034c5]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x834)[0xb6e0f834]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2fa)[0xb6e1631a]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(+0x243204)[0xb6dbc204]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2ac2)[0xb6dc44d2]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(+0x2500e1)[0xb6dc90e1]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1a1e)[0xb6dcac6e]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z10do_commandP3THD+0xe7)[0xb6dcb447]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x238)[0xb6e8b008]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /usr/sbin/mysqld(handle_one_connection+0x50)[0xb6e8b090]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39)[0xb6b3ec39]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb672778e]
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Trying to get some variables.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Some pointers may be invalid and cause the dump to abort.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Query (0x86f59010): is an invalid pointer
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Connection ID (thread ID): 37
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: Status: NOT_KILLED
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 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=off
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld:
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: information that should help you find out what is causing the crash.
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld_safe: Number of processes running now: 0
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld_safe: mysqld restarted
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: The InnoDB memory heap is disabled
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: Mutexes and rw_locks use GCC atomic builtins
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: Compressed tables use zlib 1.2.7
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: Using Linux native AIO
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: Initializing buffer pool, size = 384.0M
|
Feb 5 19:12:00 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: Completed initialization of buffer pool
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: 140205 19:12:00 InnoDB: highest supported file format is Barracuda.
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: The log sequence number in ibdata files does not match
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: the log sequence number in the ib_logfiles!
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: 140205 19:12:01 InnoDB: Database was not shut down normally!
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: Starting crash recovery.
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: Reading tablespace information from the .ibd files...
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: Restoring possible half-written data pages from the doublewrite
|
Feb 5 19:12:01 srv-eklo-dimotikes mysqld: InnoDB: buffer...
|
The corresponding my.cnf is
[client]
|
port = 3306
|
socket = /var/run/mysqld/mysqld.sock
|
|
|
[mysqld_safe]
|
socket = /var/run/mysqld/mysqld.sock
|
nice = 0
|
|
|
[mysqld]
|
user = mysql
|
pid-file = /var/run/mysqld/mysqld.pid
|
socket = /var/run/mysqld/mysqld.sock
|
port = 3306
|
basedir = /usr
|
datadir = /var/lib/mysql
|
tmpdir = /tmp
|
lc_messages_dir = /usr/share/mysql
|
lc_messages = en_US
|
character-set-server = utf8
|
collation_server = utf8_general_ci
|
skip-external-locking
|
|
|
max-connect-errors = 1000000
|
sql-mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
|
sysdate-is-now = 1
|
|
|
max_connections = 100
|
open_files_limit = 65535
|
connect_timeout = 5
|
wait_timeout = 600
|
max_allowed_packet = 16M
|
thread_cache_size = 50
|
bulk_insert_buffer_size = 16M
|
tmp_table_size = 128M
|
max_heap_table_size = 128M
|
join_buffer_size = 256K
|
#
|
#sort_buffer_size = 4M
|
#read_buffer_size = 2M
|
|
|
myisam-recover-options = FORCE,BACKUP
|
key_buffer_size = 8M
|
open-files-limit = 8192
|
table_open_cache = 4096
|
myisam_sort_buffer_size = 8M
|
concurrent_insert = 2
|
read_rnd_buffer_size = 1M
|
group_concat_max_len = 6M
|
|
|
query_cache_limit = 4M
|
query_cache_size = 24M
|
|
|
log_warnings = 2
|
|
|
slow_query_log = 1
|
slow_query_log_file = /var/log/mysql/mariadb-slow.log
|
long_query_time = 10
|
log_slow_verbosity = query_plan,innodb
|
log-queries-not-using-indexes
|
|
|
sync_master_info = 1
|
sync_relay_log = 1
|
sync_relay_log_info = 1
|
|
|
default_storage_engine = InnoDB
|
innodb = FORCE
|
innodb_strict_mode = 1
|
innodb_log_file_size = 64M
|
innodb_buffer_pool_size = 384M
|
innodb_log_buffer_size = 8M
|
innodb_file_per_table = 1
|
innodb_open_files = 1024
|
innodb_io_capacity = 400
|
innodb_flush_method = O_DIRECT
|
innodb_strict_mode = 1
|
innodb_data_file_path = ibdata1:50M:autoextend:max:1024M
|
innodb_fast_shutdown = 0
|
innodb_additional_mem_pool_size = 32M
|
innodb_flush_log_at_trx_commit = 2
|
innodb_thread_concurrency = 0
|
|
|
# REPLICATION!!!! --start--
|
server_id = 20
|
relay_log = /var/lib/mysql/mysql-relay-bin
|
read_only = 1
|
skip_slave_start = 1
|
replicate_do_db = dhmotikes
|
#
|
# # REPLICATION!!!! --end--
|
|
|
[mysqldump]
|
quick
|
quote-names
|
max_allowed_packet = 16M
|
|
|
[isamchk]
|
key_buffer = 16M
|
Thanks a lot, my.cnf did it. It was sql_mode=ONLY_FULL_GROUP_BY that made the difference.
Now I expect to be able to generate an artificial test case based on yours, but which will not contain any private data.
The crash appeared on 5.5 tree with the following revision:
------------------------------------------------------------
|
revno: 4030
|
revision-id: monty@askmonty.org-20140124125018-qwln430o4bu3pued
|
parent: monty@askmonty.org-20140124123019-2ts6q2ip6076gmqg
|
committer: Michael Widenius <monty@askmonty.org>
|
branch nick: maria-5.5
|
timestamp: Fri 2014-01-24 14:50:18 +0200
|
message:
|
Fix for MDEV-5531: double call procedure in one session - hard shutdown the server
|
Main fix was to not cache derivied tables as they may be temporary tables that are deleted before the next query.
|
This was a bit tricky as Item_field::fix_fields depended on cached_tables to be set to resolve some columns.
|
------------------------------------------------------------
|
Test case:
CREATE TABLE t1 (a INT); |
INSERT INTO t1 VALUES (1),(2); |
CREATE TABLE t2 (b INT); |
INSERT INTO t2 VALUES (3),(4); |
|
|
SET sql_mode=ONLY_FULL_GROUP_BY; |
|
|
SELECT * FROM (SELECT a FROM t1 GROUP BY a) sq JOIN t2 ON a = b; |
#3 <signal handler called>
|
#4 0x000000000069c373 in st_select_lex::set_non_agg_field_used (this=0x0, val=true) at 5.5/sql/sql_lex.h:1043
|
#5 0x00000000007fd7ad in Item_field::fix_fields (this=0x7f977fd5ecb8, thd=0x7f9781bee060, reference=0x7f977fd5ef50) at 5.5/sql/item.cc:5270
|
#6 0x000000000083c2f8 in Item_func::fix_fields (this=0x7f977fd5eec0, thd=0x7f9781bee060, ref=0x7f977fcf7cb0) at 5.5/sql/item_func.cc:204
|
#7 0x00000000005de5f8 in setup_conds (thd=0x7f9781bee060, tables=0x7f977fcf76a8, leaves=..., conds=0x7f977fcf8d40) at 5.5/sql/sql_base.cc:8833
|
#8 0x000000000069eb05 in setup_without_group (thd=0x7f9781bee060, ref_pointer_array=0x7f977fcfa8f8, tables=0x7f977fcf76a8, leaves=..., fields=..., all_fields=..., conds=0x7f977fcf8d40, order=0x0, group=0x0, hidden_group_fields=0x7f977fcf8c27) at 5.5/sql/sql_select.cc:569
|
#9 0x000000000065daa4 in JOIN::prepare (this=0x7f977fcf8928, rref_pointer_array=0x7f9781bf1cc8, tables_init=0x7f977fcf76a8, wild_num=1, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7f9781bf1a58, unit_arg=0x7f9781bf1380) at 5.5/sql/sql_select.cc:717
|
#10 0x000000000066610f in mysql_select (thd=0x7f9781bee060, rref_pointer_array=0x7f9781bf1cc8, tables=0x7f977fcf76a8, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f977fcf8908, unit=0x7f9781bf1380, select_lex=0x7f9781bf1a58) at 5.5/sql/sql_select.cc:3059
|
#11 0x000000000065ce05 in handle_select (thd=0x7f9781bee060, lex=0x7f9781bf12d0, result=0x7f977fcf8908, setup_tables_done_option=0) at 5.5/sql/sql_select.cc:319
|
#12 0x00000000006365e7 in execute_sqlcom_select (thd=0x7f9781bee060, all_tables=0x7f977fcf76a8) at 5.5/sql/sql_parse.cc:4688
|
#13 0x000000000062f79f in mysql_execute_command (thd=0x7f9781bee060) at 5.5/sql/sql_parse.cc:2232
|
#14 0x0000000000638cf6 in mysql_parse (thd=0x7f9781bee060, rawbuf=0x7f977fd5d078 "SELECT * FROM (SELECT a FROM t1 GROUP BY a) sq JOIN t2 ON a = b", length=63, parser_state=0x7f97807b5630) at 5.5/sql/sql_parse.cc:5799
|
#15 0x000000000062cd17 in dispatch_command (command=COM_QUERY, thd=0x7f9781bee060, packet=0x7f9780eff061 "SELECT * FROM (SELECT a FROM t1 GROUP BY a) sq JOIN t2 ON a = b", packet_length=63) at 5.5/sql/sql_parse.cc:1078
|
#16 0x000000000062beba in do_command (thd=0x7f9781bee060) at 5.5/sql/sql_parse.cc:793
|
#17 0x000000000072d982 in do_handle_one_connection (thd_arg=0x7f9781bee060) at 5.5/sql/sql_connect.cc:1266
|
#18 0x000000000072d441 in handle_one_connection (arg=0x7f9781bee060) at 5.5/sql/sql_connect.cc:1181
|
#19 0x000000000098592d in pfs_spawn_thread (arg=0x7f9781bf59e0) at 5.5/storage/perfschema/pfs.cc:1015
|
#20 0x00007f9786780b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
|
#21 0x00007f97852cfa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Stack trace from
revision-id: elenst@wheezy-64.home-20140205102537-7ern5gfca6a6ojg3
|
revno: 4055
|
branch-nick: 5.5
|
Hi Elena,
Is there a way to get back 5.5.34 in the repository or some other way to downgrade for my Debian servers? I want to downgrade and I need to do it now, since we are in the process of developing a web application that uses MariaDB with master/slaves setup.
Hi Vasilis,
Yes, 5.5.34 is still in many mirrors, links to the repo usually look like this: http://mirrors.supportex.net/mariadb/mariadb-5.5.34/repo/debian/ .
But if it is this bug that makes you downgrade, maybe it will be easier to remove ONLY_FULL_GROUP_BY temporarily from your config file, or, since you are developing the application and hence have access to its code, make it to unset ONLY_FULL_GROUP_BY dynamically upon connection (again, temporarily, until the bug is fixed)?
Hi Elena,
Ok, I can do that, but are you sure 5.5.35 is totally crash free? For example, yesterday, after I upgraded my Windows XP box to 5.5.35 and while working with MySQL Workbench, for some reason, the latter crashed (not something new since MySQL Workbench is very unstable and buggy), but after trying to connect with another client, I discovered that mysqld had also crashed, which is something very very rare. At that point, I did not run this query which caused the issue with the ONLY_FULL_GROUP_BY setting, it's something that a colleague of mine discovered the issue with the specific query.
Are there any blocking bugs for 5.5.35 (that crash the server I mean)?
are you sure 5.5.35 is totally crash free?
On the contrary, I'm 100% sure that there is no version of MariaDB or MySQL server that is crash-free, and 5.5.35 is not an exception. As you can see in release notes for any version, there are always fixed crashing bugs. MariaDB change log states it explicitly, MySQL log is a bit more obscure about it, but all the same, crashes do happen and get fixed all the time. Most of them never affect you, some do, in which case you of course need a suggestion on how to deal with them until they are fixed. It can only be done on case-by-case basis.
And we would like more about the other crash that you mentioned, of course – if you have any information about it, could you please open a separate bug report?
On the contrary, I'm 100% sure that there is no version of MariaDB or MySQL server that is crash-free, and 5.5.35 is not an exception.
Well, I meant if there are any known blocking bugs.
Ok, I will temporarily remove ONLY_FULL_GROUP_BY from the configuration files.
And we would like more about the other crash that you mentioned, of course – if you have any information about it, could you please open a separate bug report?
I'm sorry, but I cannot reproduce this condition. I'm frustrated with MySQL Workbench and I'm taking my chances with HeidiSQL, i just hope it's better and more stable. Maybe you should consider forking it and making it better, just more stable. 
Thank you very much for your help.
Are there any blocking bugs for 5.5.35 (that crash the server I mean)?
There are several known crashing or potentially crashing bugs in 5.5.35, but none of them is a regression from 5.5.34 (like the one that you filed), and most of them are related to rather specific areas: virtual columns, spatial functions, prepared statements, dynamic change of certain system variables in concurrent environment, things like that.
The problem was that in a few places, we still depended on that cached_table would have a value. I have now fixed this. Will run tests and push
Fixed and pushed
Thank you guys, you are great!
How soon will 5.5.36 get released, do you have a release date?
Currently the planned release date is 2014-02-21. It can change later, but should not change too much.
You can always find the latest known plan at the main page of our JIRA (https://mariadb.atlassian.net/secure/Dashboard.jspa), "Road Map" section.