Hi serg, ptal thanks:

0fa141ebb46 upstream/bb-10.5-mdev-36138 MDEV-36138 Server null-pointer crash at startup when tmptables left in --tmpdir

0fa141ebb46 is ok to push, thanks

It would be good to have some indication of the seriousness of this bug - what are the situations that cause it to trigger, how many users are likely to be affected?

It does trigger in real life (it was found because it happened in our own Buildbot), but it does not seem to occur for all temporary tables (not sure if they unlink their open .frm or maybe don't create .frm in the first place). It makes a big difference if this is something that will affect a large majority of server crashes, or if it only occurs in special situations (specific storage engine or something?).

The test case in the patch 0fa141ebb46 does not show a real scenario where the bug can trigger, it manually copies in a .frm to the tmpdir.

knielsen: do you have a link to the buildbot failure?

Thanks for the review - pushed 0fa141ebb4639c5c6c4b5d990f448a932fd095a8 to 10.5

ycp It's not a buildbot failure, it was our own servers running the Buildbot infrastructure this happened.
There is a MariaDB slave from the Buildbot master database (used for cross-reference maybe), it crashed due to OOM, and then it could not start again because of this bug.

There is a zulip discussion about the incidence:
https://mariadb.zulipchat.com/#narrow/channel/118759-general/topic/MariaDB.2010.2E11.2E11.20not.20recovering.20from.20crash

Normally temporary tables does not have a .frm file, only storage engine files in /tmp
I found at least one case where a .frm file is created.
When creating a temporary table with federatedx that uses discovery, then a .frm table will be created in /tmp and the problem described in this ticket will happen.

For example:

CREATE temporary TABLE foo3 ENGINE=FEDERATED CONNECTION='mysql://monty@storm:3307/test/foo';

When the table definition is provided, no tmp table is created:

MariaDB [test2]> create temporary table foo (a int) engine=federated connection='server_one';

It fits, the setup for the multi-CI cross-reference in the foundation buildbot is rather complicated, and it does involve a federated table.

I tried monty's scenario in the testcase federated.federatedx (see below) but it does not crash either. The first ls outputs a #sql....frm file as expected, but inside mysql_rm_tmp_tables() during the server restart, the tmpdir already appears to be empty, so it could have been removed in a cleanup in the server shutdown. Or it could be some extra setup of this specific test.

modified   mysql-test/suite/federated/federatedx.test

@@ -84,16 +84,15 @@ DROP TABLE IF EXISTS federated.t1;

 # # correct connection, same named tables

 --replace_result $SLAVE_MYPORT SLAVE_PORT

-eval CREATE TABLE federated.t1 (

-    `id` int(20) NOT NULL,

-    `group` int NOT NULL default 0,

-    `a\\\\b` InT NOT NULL default 0,

-    `a\\\\` int NOT NULL default 0,

-    `name` varchar(32) NOT NULL default ''

-    )

+eval CREATE TEMPORARY TABLE federated.t1

   ENGINE="FEDERATED" DEFAULT CHARSET=latin1

   CONNECTION='mysql://root@127.0.0.1:$SLAVE_MYPORT/federated/t1';

+let $MYSQLD_TMPDIR=`SELECT @@tmpdir`;

+exec ls $MYSQLD_TMPDIR;

+--source include/restart_mysqld.inc

+exec ls $MYSQLD_TMPDIR;

+

 INSERT INTO federated.t1 (id, name) VALUES (1, 'foo');

 INSERT INTO federated.t1 (id, name) VALUES (2, 'fee');

 INSERT INTO federated.t1 (id, `group`) VALUES (3, 42);