tag:blogger.com,1999:blog-3080615211468083537.post8436318445146802248..comments2023-09-27T11:36:08.392+03:00Comments on Blog of (former?) MySQL Entomologist: Fun with Bugs #75 - On MySQL Bug Reports I am Subscribed to, Part XIIValerii Kravchukhttp://www.blogger.com/profile/13158916419325454260noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3080615211468083537.post-70156702531511257932018-12-15T19:16:25.928+02:002018-12-15T19:16:25.928+02:00I am the author of the test mentioned in Bug #9316...I am the author of the test mentioned in Bug #93165: innodb.log_file_name.<br /><br />For what it is worth, one of the first things that I fixed in MariaDB Server in 10.2 between joining the company in late 2016 and the GA release in 2017 were the various memory leaks in InnoDB startup and shutdown. I not only wrote new recovery tests to uncover bugs, but also rewrote a number of old tests so that they use the normal server restart mechanism, which allows all parts of the tests to be run not only with AddressSanitizer, but also with Valgrind. Also, I cleaned up many tests that used to use DBUG_SUICIDE for killing the server, and used an external kill instead. In this way, the tests can be run under Valgrind, which still remains the primary tool of choice for detecting use of uninitialized variables.<br /><br />In MySQL 5.7, errors in InnoDB startup and shutdown are maybe not considered as bad, because InnoDB is a mandatory storage engine. In MariaDB, the server can start up even if InnoDB fails to start due to a problem.<br /><br />I have more confidence in the quality of the InnoDB crash recovery code if I can actually exercise all the code also with memory debugging tools.Marko Mäkelähttps://www.blogger.com/profile/01918141282242941322noreply@blogger.com