[MDEV-28579] 0xc0000005 crash in Query_cache::unlink_table Created: 2022-05-16  Updated: 2022-07-18  Resolved: 2022-07-18

Status: Closed
Project: MariaDB Server
Component/s: Query Cache
Affects Version/s: 10.3.8
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: hangsung1 Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: crash, innodb
Environment:

Windows Server 2019 x64


Attachments: File WIN-TEST.err     File create_table.sql     File my.ini    

 Description   

220428 17:00:08 [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.3.8-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=70
max_threads=502
thread_count=76
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1233091 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1cd4865c028
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!Query_cache::unlink_table()[sql_cache.cc:3613]
mysqld.exe!Query_cache::register_all_tables()[sql_cache.cc:3489]
mysqld.exe!Query_cache::store_query()[sql_cache.cc:1555]
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:6542]
mysqld.exe!mysql_execute_command()[sql_parse.cc:3765]
mysqld.exe!mysql_parse()[sql_parse.cc:8078]
mysqld.exe!dispatch_command()[sql_parse.cc:1849]
mysqld.exe!do_command()[sql_parse.cc:1391]
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1402]
mysqld.exe!handle_one_connection()[sql_connect.cc:1310]
mysqld.exe!pthread_start()[my_winthread.c:62]
mysqld.exe!thread_start<unsigned int (__cdecl*)(void * __ptr64)>()[thread.cpp:115]
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x1cd48601170): SELECT * FROM trace_FAB1_TEST WHERE FabId = 'FAB1' AND EquipmentId = 'TEST' AND Trid = 'DEFAULT' AND Stime >= '2022/04/26 07:49:02.032' AND Stime <= '2022/04/26 13:07:24.445' LIMIT 5000, 5000
Connection ID (thread ID): 370
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=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on



 Comments   
Comment by Daniel Black [ 2022-05-16 ]

This looks like it could be MDEV-5924. Please try with a 10.3.24+ version (or disable your query cache).

Comment by hangsung1 [ 2022-05-17 ]

Is the solution for the 10.3.24+ version (or does not use query cache)?

Comment by Elena Stepanova [ 2022-06-15 ]

Sorry the question is unclear.
10.3.8 is almost 4-year-old, ~25 releases behind the current 10.3. There have been lots of bugfixes since then, among them MDEV-5924 which was fixed in 10.3.24 and looks similar to what you had. You were advised to upgrade to a version containing the fix. Alternatively, if you can't or don't want to upgrade on some reason, you can work around the problem by disabling query cache.

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