Details
-
Type:
Bug
-
Status: Closed
-
Resolution: Duplicate
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
Description
When attempting to perform an INSERT query that contains nested sub-SELECTs MariaDB 5.5.23 crashes with the following error:
This happened on Ubuntu 10.04.3 LTS using the stable version of MariaDB in the lucid release repo.
The system is running kernel 2.6.32-33-server on amd64 (4 logical CPUs). 16gb of RAM. We are using ext4 on an md raid10 volume to store the data directory. The system does not run any other significant processes, just a pretty vanilla installation of Ubuntu running MariaDB.
The server is not participating in replication. No other activity on the server at the time of crash except running the query below. (This server is non-production).
Unfortunately I cannot provide a core dump due to security requirements (we are dealing with customer data). Names/values have been redacted as appropriate below for the same reason.
Contents of error log with server compiled in debug mode at time of crash:
--SNIP--
InnoDB: DEBUG: update_statistics for redacted/#sql-6f38_4.
InnoDB: DEBUG: update_statistics for redacted/#sql-6f38_4.
InnoDB: DEBUG: update_statistics for redacted/platform_app.
120517 11:29:50 [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 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: 5.5.23-MariaDB-debug-log
key_buffer_size=16777216
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 = 351502 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x7f56780257e0
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 = 0x7f59c35e0e40 thread_stack 0x30000
mysys/stacktrace.c:246(my_print_stacktrace)[0xc7cb8a]
sql/signal_handler.cc:172(handle_fatal_signal)[0x7cfecd]
:0()[0x7f59c31f38f0]
sql/item.cc:9588(Item_ref::update_used_tables())[0x7fa5b0]
sql/item_func.cc:447(Item_func::update_used_tables())[0x8307be]
sql/sql_lex.cc:3786(st_select_lex::update_used_tables())[0x6084e1]
sql/sql_select.cc:975(JOIN::optimize())[0x642c2a]
sql/item_subselect.cc:2934(subselect_single_select_engine::exec())[0x8738c7]
sql/item_subselect.cc:597(Item_subselect::exec())[0x86c733]
sql/item_subselect.cc:1113(Item_singlerow_subselect::val_int())[0x86df32]
sql/item.cc:5888(Item::save_in_field(Field*, bool))[0x7eef5f]
sql/sql_base.cc:8823(fill_record)[0x5bd796]
sql/sql_base.cc:8880(fill_record_n_invoke_before_triggers(THD*, List<Item>&, List<Item>&, bool, Table_triggers_list*, trg_event_type))[0x5bd980]
sql/sql_insert.cc:886(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool))[0x5f4866]
sql/sql_parse.cc:2917(mysql_execute_command(THD*))[0x613630]
sql/sql_parse.cc:5731(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x61b7b6]
sql/sql_parse.cc:1057(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x60eea2]
sql/sql_parse.cc:794(do_command(THD*))[0x60e13c]
sql/sql_connect.cc:1253(do_handle_one_connection(THD*))[0x713ed6]
sql/sql_connect.cc:1169(handle_one_connection)[0x713999]
:0()[0x7f59c31ea9ca]
:0()[0x7f59c1f3d70d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f56802c7d38): is an invalid pointer
Connection ID (thread ID): 4
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=off
--SNIP--
Query in question that caused the server to crash:
--SNIP--
INSERT INTO platform_app (platform_id, visible, name, `order`, type, url_action, url_about,
access_level, `restrict`, `hidden`, parent_platform_app_id, module)
VALUES (
2,1,'redacted',1,0,'redacted','',0,'','',
(
SELECT platform_app_id FROM (
SELECT * FROM platform_app
) AS temp WHERE temp.name = 'redacted'
),
''
)
--SNIP--
SHOW CREATE TABLE for the table in question (platform_app):
--SNIP--
CREATE TABLE `platform_app` (
`platform_app_id` int(11) NOT NULL AUTO_INCREMENT,
`platform_id` int(11) NOT NULL,
`visible` tinyint(1) NOT NULL,
`name` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`order` int(11) NOT NULL,
`type` int(11) NOT NULL,
`url_action` varchar(192) COLLATE utf8_unicode_ci DEFAULT NULL,
`url_about` varchar(192) COLLATE utf8_unicode_ci DEFAULT NULL,
`access_level` int(11) NOT NULL,
`restrict` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
`hidden` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
`parent_platform_app_id` int(11) NOT NULL DEFAULT '0',
`module` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`platform_app_id`),
KEY `platform_id` (`platform_id`)
) ENGINE=InnoDB AUTO_INCREMENT=115 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
--SNIP--
Contents of my.cnf:
--SNIP--
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
syslog
[mysqld]
user = mysql
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
bind-address = 10.0.0.98
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
general_log_file = /var/log/mysql/mysql.log
log_error = /var/log/mysql/error.log
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 5
max_binlog_size = 100M
server-id=23
replicate-same-server-id=0
log-slave-updates
innodb_buffer_pool_size = 12G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table
innodb_flush_method = O_DIRECT
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[isamchk]
key_buffer = 16M
--SNIP--
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: MariaDB crashes on insert containing doubly nested subselect
Hi Jason,
Thank you for the report. The crash is reproducible on 5.5.23 just as you described it, but it seems to be gone in the current 5.5 tree. We had several fixes in this area, so it's likely to have been fixed along with them, but we'll double-check to make sure that it was not just masked.
5.5.24 release is due this week.
Meanwhile, as a workaround till you can upgrade, you might try to turn off derived_merge in your optimizer switch:
optimizer_switch=derived_merge=off
or, do it at runtime in the session which runs the query. Either should help.
As a side note (not related to the crash), the query seems a bit risky – it only works properly if the innermost subquery returns exactly 1 row; if it returns nothing, the whole query fails because parent_platform_app_id cannot be null, and if there are multiple matches, it fails with ER_SUBQUERY_NO_1_ROW (subquery returns more than 1 row). Not sure if it's expected.