[MDEV-4316] MariaDB server crash with signal 11 Created: 2013-03-22  Updated: 2013-05-27  Resolved: 2013-04-08

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.1, 5.5.30, 5.3.12
Fix Version/s: 10.0.2, 5.5.31, 5.3.13

Type: Bug Priority: Major
Reporter: Aurélien Bras Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: upstream
Environment:

Debian wheezy


 Description   

The server crash in loop (restarted by mysqld_safe), it's
a shared hosting with more than 1000 databases, but always sames
request seems to crash the serveur (always phpwebgallery).
Full crash report that I can see in my syslog file :

130322 11:04:00 [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.
 
 
 
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.30-MariaDB-mariadb1~wheezy
 
key_buffer_size=2147483648
 
read_buffer_size=1048576
 
max_used_connections=15
 
 
 
max_threads=502
 
thread_count=1
 
It is possible that mysqld could use up to
 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 3132316 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x7fcab1e4c700
 
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 = 0x7fcab4501e70 thread_stack 0x30000
 
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7fcb8001ef7b]
 
/usr/sbin/mysqld(handle_fatal_signal+0x422)[0x7fcb7fc5d422]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7fcb7f364030]
 
/usr/sbin/mysqld(+0x790cb9)[0x7fcb7ff23cb9]
 
/usr/sbin/mysqld(_ZN15Item_func_match11init_searchEb+0x15b)[0x7fcb7fcb65db]
 
/usr/sbin/mysqld(_ZN15Item_func_match11init_searchEb+0x9d)[0x7fcb7fcb651d]
 
/usr/sbin/mysqld(_Z12init_ftfuncsP3THDP13st_select_lexb+0x60)[0x7fcb7faec730]
 
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x1a18)[0x7fcb7fb6d188]
 
/usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select
 
 
 
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2c3)[0x7fcb7fb75203]
 
/usr/sbin/mysqld(+0x38e851)[0x7fcb7fb21851]
 
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4261)[0x7fcb7fb2bbb1]
 
/usr/sbin/mysqld(+0x39a677)[0x7fcb7fb2d677]
 
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1b24)[0x7fcb7fb2fad4]
 
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x21b)[0x7fcb7fbdf9ab]
 
/usr/sbin/mysqld(handle_one_connection+0x51)[0x7fcb7fbdfa31]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7fcb7f35bb50]
 
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fcb7dc7fa7d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7fcb87e63b78): SELECT id, MATCH(ft) AGAINST( "deom da vel" IN BOOLEAN MODE) AS q FROM (
 
SELECT
 
 i.id, CAST( CONCAT_WS(" ",
 
    IFNULL(i.name,""),
 
    IFNULL(i.comment,""),
 
    IFNULL(GROUP_CONCAT(DISTINCT co.content),""),
 
    IFNULL(GROUP_CONCAT(DISTINCT c.dir),""),
 
    IFNULL(GROUP_CONCAT(DISTINCT c.name),""),
 
    IFNULL(GROUP_CONCAT(DISTINCT c.comment),"") ) AS CHAR) AS ft
 
FROM (
 
  (
 
    phpwebgallery_images i LEFT JOIN phpwebgallery_comments co on i.id=co.image_id
 
  )
 
    INNER JOIN
 
  phpwebgallery_image_category ic on ic.image_id=i.id
 
  )
 
    INNER JOIN
 
  phpwebgallery_categories c on c.id=ic.category_id
 
 
 
GROUP BY i.id) AS Y
 
WHERE MATCH(ft) AGAINST( "deom da vel" IN BOOLEAN MODE)
 
 
 
Connection ID (thread ID): 13272
 
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



 Comments   
Comment by Elena Stepanova [ 2013-03-22 ]

Also reproducible on MySQL 5.6.10 and filed as http://bugs.mysql.com/bug.php?id=68751

  1. Test case:

CREATE TABLE t1 (ft TEXT) ENGINE=MyISAM;
INSERT INTO t1 VALUES ('test1'),('test2');

SELECT DISTINCT MATCH(ft) AGAINST( "test" IN BOOLEAN MODE) FROM
( SELECT DISTINCT ft FROM t1 ) AS t;

  1. End of test case

On MariaDB reproducible with the default optimizer_switch as well as with all OFF values.

Comment by Elena Stepanova [ 2013-03-22 ]

While the bug is reproducible on MySQL too, it's only with 5.6, while on MariaDB it's 5.3+ ; so even if/when it gets fixed in MySQL, the fix won't automatically appear in previous MariaDB versions.

Sergei,

could you please decide whether it needs to be assigned to somebody, or whether we should wait for the upstream fix and backport it to previous versions, or it should be handed in some other way?

Comment by Aurélien Bras [ 2013-03-23 ]

There is a work around ?

Comment by Elena Stepanova [ 2013-03-23 ]

Unfortunately, I haven't found any so far (assuming you can't change the query itself). Maybe Sergei will have an idea.

Comment by Elena Stepanova [ 2013-03-25 ]

Note (from IRC discussion): after the bug gets fixed in 5.3, it would be good to merge the fix to 5.5 right away, so the reporter could pick up the fix and start using it immediately, to avoid further crashes in production.

Comment by Aurélien Bras [ 2013-03-27 ]

I cannot keep this bug in production more than one day or two, can I have an update ? If not, I should prepare to migrate to a stable version and anticipate it.

Thanks for your answer.

Comment by Sergei Golubchik [ 2013-03-27 ]

Unfortunately, there's no stable version without this bug, all MySQL and MariaDB versions are affected.
But we'll have it fixed soon.

Comment by Aurélien Bras [ 2013-04-05 ]

Can I have an update ? A date for the 5.5.31 release ?

Thanks.

Comment by Sergei Golubchik [ 2013-04-05 ]

I'm working on it right now, hopefully it'll be fixed today.

As for the release date - sorry, we don't know. We cannot release MariaDB 5.5.31 before MySQL 5.5.31 is released, and Oracle doesn't disclose its release schedule.

Comment by Patryk Pomykalski [ 2013-04-05 ]

According to changelog it will be released today
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html

Comment by Elena Stepanova [ 2013-04-05 ]

If I remember correctly, Aurélien said it would be possible to pick up sources and build binaries locally, so the undefined release date shouldn't be a big issue – as soon as the bugfix is pushed into the tree, it will be available.

Comment by Aurélien Bras [ 2013-04-05 ]

Yes I can build my own package if I have a patch, but now I hope for the 5.5.31 release

Comment by Sergei Golubchik [ 2013-04-08 ]

pushed in 5.3

Comment by Aurélien Bras [ 2013-04-12 ]

MySQL 5.5.31 do not seems to be out, can you provide a patch for the 5.5.30 version ?

Comment by Sergei Golubchik [ 2013-04-12 ]

http://bazaar.launchpad.net/~maria-captains/maria/5.3/revision/3650

Comment by Aurélien Bras [ 2013-04-18 ]

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html is out , say me when you have the schedule for MariaDB 5.5.31.

Comment by Aurélien Bras [ 2013-05-27 ]

I confirm issue is fixed in MariDB 5.5.31, thanks.

Generated at Thu Feb 08 06:55:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.