[MDEV-21919] Crash on mariadb:10.5.1 (docker) when executing invalid query Created: 2020-03-11  Updated: 2020-06-28  Resolved: 2020-06-28

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.5.1
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Timon Vogt Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: crash, need_feedback
Environment:
  • docker v19.03.5 on Windows 10
  • image mariadb:10.5.1-bionic
  • access over Java/Spring Boot (v2.2.0.RELEASE)

Attachments: File mariadb.cnf     Text File mysql_error.log    
Issue Links:
Relates
relates to MDEV-21824 0xc0000005 crash Closed

 Description   

Hello,
I am hoping this is the right place to report this and I did not miss an already filed bug, otherwise feel free to delete/move.

The following occurred:
While testing a Spring Boot API (using the com.mysql.cj.jdbc.Driver to connect to the database), also invalid SQL Queries were tested (tested were "SELECT * FRAM applications;" "SLECT * FROM applications;" and "SELECT;"). These resulted in a crash of mariadb and a restart of the software. Correct queries (also after the restart of mariadb) did not result in an crash. The error-log contains the following. The complete log and the .cnf file is attached. Please let me know if you need any more information.

[ERROR] mysqld got signal 11 ;
...
Server version: 10.5.1-MariaDB-1:10.5.1+maria~bionic-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=10
max_threads=102
thread_count=12
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 760270 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7fbd2c000c08
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 = 0x7fbd8c2bdd98 thread_stack 0x3c000
mysqld(my_print_stacktrace+0x2e)[0x564e6a20379e]
Printing to addr2line failed
mysqld(handle_fatal_signal+0x515)[0x564e69c473c5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fbd94280890]
mysqld(my_wc_to_printable_generic+0x3a)[0x564e6a25559a]
mysqld(my_convert_using_func+0x85)[0x564e6a255795]
mysqld(_Z21convert_error_messagePcmPK15charset_info_stPKcmS2_Pj+0x4b)[0x564e69a17ccb]
mysqld(_Z21net_send_error_packetP3THDjPKcS2_+0x96)[0x564e6999ad46]
mysqld(_ZN8Protocol13end_statementEv+0xb9)[0x564e6999af59]
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x5be)[0x564e69a4c74e]
mysqld(_Z10do_commandP3THD+0x138)[0x564e69a4bca8]
mysqld(_Z24do_handle_one_connectionP7CONNECTb+0x3ee)[0x564e69b3f5be]
mysqld(handle_one_connection+0x4b)[0x564e69b3f77b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7fbd942756db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fbd9367388f]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fbd2c0100e0): SELECT
Connection ID (thread ID): 29
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=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
 
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...
Working directory at /var/lib/mysql
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             unlimited            unlimited            processes 
Max open files            1048576              1048576              files     
Max locked memory         83968000             83968000             bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       7896                 7896                 signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core



 Comments   
Comment by Elena Stepanova [ 2020-05-27 ]

Is it still happening?
There were two similar issues fixed in 10.5.2 and 10.5.3 accordingly: MDEV-21824 and MDEV-22043. Hopefully one of them has fixed this as well.

Generated at Thu Feb 08 09:10:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.