[MDEV-28186] crash on startup after crash while regular use Created: 2022-03-28  Updated: 2022-05-29  Resolved: 2022-05-29

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.4.23, 10.7.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Maxim Assignee: Michael Widenius
Resolution: Incomplete Votes: 0
Labels: crash
Environment:

Windows 11 x86


Attachments: File mysqld.dmp    

 Description   

220328 20:30:57 [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.7.3-MariaDB-log
key_buffer_size=209715200
read_buffer_size=1048576
max_used_connections=0
max_threads=65537
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 335757576 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
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...
server.dll!translog_sync()[ma_loghandler.c:8947]
server.dll!maria_end()[ma_init.c:95]
server.dll!maria_panic()[ma_panic.c:136]
server.dll!ha_maria_init()[ha_maria.cc:3853]
server.dll!ha_initialize_handlerton()[handler.cc:649]
server.dll!plugin_initialize()[sql_plugin.cc:1462]
server.dll!plugin_init()[sql_plugin.cc:1755]
server.dll!init_server_components()[mysqld.cc:5083]
server.dll!mysqld_main()[mysqld.cc:5698]
mysqld.exe!__scrt_common_main_seh()[exe_common.inl:288]
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.



 Comments   
Comment by Sergei Golubchik [ 2022-03-30 ]

there's likely more than one bug here. But at the very least, if translog_init() failed in ha_maria_init() at ha_maria.cc:3853, then maria_end() at ma_init.c:95 should not do translog_sync().

Comment by Michael Widenius [ 2022-03-31 ]

The code line is:

translog_sync_files(min, max, sync_log_dir >= TRANSLOG_SYNC_DIR_ALWAYS);

I cannot see any way this line could fail. Could be inside translog_sync_files(), but then
there is still something wrong with the back trace.
Is the windows version compiled with asserts enabled?
It if is, then something is very strange as we should have got an assert before an
exception in this code.

What was in the error log before the exception?
If translog_init() would have failed, this should have been seen in the .error log.
Under what circumstances this this error happen?
How was mariadbd started?
Getting a copy of the aria log files could help find the issue.

I added some simulation of failed log init, and found one case where one could get an assert if trans_init() failed in an unlikely spot, which I have now fixed. However it is very unlikely that this has anything to do with the reported issue.

Comment by Elena Stepanova [ 2022-05-01 ]

sailormax,
Can you provide the full error log and the config file at least? Aria log files mentioned in the previous comment would be a plus, if they are still available.

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