[MDEV-16002] Crash in table_cache code Created: 2018-04-24  Updated: 2020-08-25  Resolved: 2018-04-27

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Spider
Affects Version/s: 10.2.14
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: need_feedback

Issue Links:
Duplicate
duplicates MDEV-15936 Crashes with varying stack trace on W... Closed

 Description   

Error log output:

2018-04-24 8:13:19 6264 [Warning] Aborted connection 110550 to db: 'dilas' user: 'op' host: '172.20.13.19' (Got timeout reading communication packets)
180424 8:39:29 [ERROR] mysqld got exception 0xc0000005 ;
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 https://mariadb.com/kb/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.2.14-MariaDB-log
key_buffer_size=2147483648
read_buffer_size=10485760
max_used_connections=236
max_threads=65537
thread_count=213
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2126896 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x278c5ce3298
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...
mysqld.exe!??1Trigger@@QEAA@XZ()
mysqld.exe!??1Table_triggers_list@@QEAA@XZ()
mysqld.exe!??1Table_cache_instance@@QEAA@XZ()
mysqld.exe!?tc_add_table@@YAXPEAVTHD@@PEAUTABLE@@@Z()
mysqld.exe!?open_table@@YA_NPEAVTHD@@PEAUTABLE_LIST@@PEAVOpen_table_context@@@Z()
mysqld.exe!?open_and_lock_tables@@YA_NPEAVTHD@@AEBUDDL_options_st@@PEAUTABLE_LIST@@_NIPEAVPrelocking_strategy@@@Z()
mysqld.exe!?open_tables@@YA_NPEAVTHD@@AEBUDDL_options_st@@PEAPEAUTABLE_LIST@@PEAIIPEAVPrelocking_strategy@@@Z()
mysqld.exe!?open_and_lock_tables@@YA_NPEAVTHD@@AEBUDDL_options_st@@PEAUTABLE_LIST@@_NIPEAVPrelocking_strategy@@@Z()
mysqld.exe!?execute_init_command@@YAXPEAVTHD@@PEAUst_mysql_lex_string@@PEAUst_mysql_rwlock@@@Z()
mysqld.exe!?mysql_execute_command@@YAHPEAVTHD@@@Z()
mysqld.exe!?mysql_parse@@YAXPEAVTHD@@PEADIPEAVParser_state@@_N3@Z()
mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PEAVTHD@@PEADI_N3@Z()
mysqld.exe!?do_command@@YA_NPEAVTHD@@@Z()
mysqld.exe!?pool_of_threads_scheduler@@YAXPEAUscheduler_functions@@PEAKPEAI@Z()
mysqld.exe!?tp_callback@@YAXPEAUTP_connection@@@Z()
ntdll.dll!RtlReleaseSRWLockExclusive()
ntdll.dll!RtlReleaseSRWLockExclusive()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x278b09fd9e0): SELECT `ID` ,`versrev`.`ID` FROM `versrev` ORDER BY `versrev`.`ID` DESC
Connection ID (thread ID): 171023
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=on,engine_condition_pushdown=on,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=off,condition_pushdown_for_derived=on

Unmangled backtrace:

mysqld.exe!public: __cdecl Trigger::~Trigger(void) __ptr64
 
mysqld.exe!public: __cdecl Table_triggers_list::~Table_triggers_list(void) __ptr64
 
mysqld.exe!public: __cdecl Table_cache_instance::~Table_cache_instance(void) __ptr64
 
mysqld.exe!void __cdecl tc_add_table(class THD * __ptr64,struct TABLE * __ptr64)
 
mysqld.exe!BOOL __cdecl open_table(class THD * __ptr64,struct TABLE_LIST * __ptr64,class Open_table_context * __ptr64)
 
mysqld.exe!BOOL __cdecl open_and_lock_tables(class THD * __ptr64,struct DDL_options_st const & __ptr64,struct TABLE_LIST * __ptr64,BOOL,unsigned int,class Prelocking_strategy * __ptr64)
 
mysqld.exe!BOOL __cdecl open_tables(class THD * __ptr64,struct DDL_options_st const & __ptr64,struct TABLE_LIST * __ptr64 * __ptr64,unsigned int * __ptr64,unsigned int,class Prelocking_strategy * __ptr64)
 
mysqld.exe!BOOL __cdecl open_and_lock_tables(class THD * __ptr64,struct DDL_options_st const & __ptr64,struct TABLE_LIST * __ptr64,BOOL,unsigned int,class Prelocking_strategy * __ptr64)
 
mysqld.exe!void __cdecl execute_init_command(class THD * __ptr64,struct st_mysql_lex_string * __ptr64,struct st_mysql_rwlock * __ptr64)
 
mysqld.exe!int __cdecl mysql_execute_command(class THD * __ptr64)
 
mysqld.exe!void __cdecl mysql_parse(class THD * __ptr64,char * __ptr64,unsigned int,class Parser_state * __ptr64,BOOL,BOOL)
 
mysqld.exe!BOOL __cdecl dispatch_command(enum enum_server_command,class THD * __ptr64,char * __ptr64,unsigned int,BOOL,BOOL)
 
mysqld.exe!BOOL __cdecl do_command(class THD * __ptr64)
 
mysqld.exe!void __cdecl pool_of_threads_scheduler(struct scheduler_functions * __ptr64,unsigned long * __ptr64,unsigned int * __ptr64)
 
mysqld.exe!void __cdecl tp_callback(struct TP_connection * __ptr64)
 
ntdll.dll!RtlReleaseSRWLockExclusive()
 
ntdll.dll!RtlReleaseSRWLockExclusive()
 
KERNEL32.DLL!BaseThreadInitThunk()
 
ntdll.dll!RtlUserThreadStart()



 Comments   
Comment by Hartmut Holzgraefe [ 2018-04-24 ]

Looking again the actual table being used in SELECT may not be a Spider table after all ... I will update ticket information as soon as I get information feedback on this ...

Comment by Hartmut Holzgraefe [ 2018-04-24 ]

Removed "Spider" from the title, the crashing instance is using Spider tables, but the crash is on an InnoDB table.

Comment by Jacob Mathew (Inactive) [ 2018-04-25 ]

Kentoku and I have analyzed the information for this bug. It looks to us that this problem is not a Spider problem. It may also not be a storage engine problem. Marko should be able to determine whether or not it is an InnoDB problem. We think it is not. We think the problem is elsewhere in the MariaDB server code.

Comment by Vladislav Vaintroub [ 2018-04-26 ]

That stack trace is broken (sometimes they are not very great, depending on where memory is overriden). It makes sense in such cases to add core-file to the my.ini options, so mysqld.dmp is produced, and then attach the dmp file to the report- the dumps are reasonably small, especially when compressed.

Comment by Marko Mäkelä [ 2018-04-26 ]

I agree with the analysis that this does not look like a storage engine problem, but rather a problem with the table cache, which would be svoj’s area of responsibility. In any case, we need a better stack trace or a core dump.

Comment by Hartmut Holzgraefe [ 2018-04-27 ]

We can close this one as duplicate of MDEV-15936, it is from the same instance, and we now have a total of 10 crashes, with 8 more or less different backtraces. So it looks more like a general stack smashing bug that should be handled in a single place.

Generated at Thu Feb 08 08:25:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.