Fustini,

Before I can answer that, I need to understand something. This problem has apparently been around forever, in previous releases, in MySQL, everywhere. How did it happen that it suddenly started bothering you now? Has anything in your procedure changed?

@Elena: that's what I was pointing out:
I have a cron job running every night for years the runs mysqloptimize -A
Two things changed recently updated mariadb 5.5.x -> 10.0.x
Upgraded tables from MyIsam to Aria.

Sine Mariadb 10.0 I can see is from time to time when mysqloptimize runs, one of the tables got stuck and runs into state "crashed". Since this doesn't happen every night, I assume some concurrent access to the table during optimize, which is interpreted as "crash".
The result of the next run of mysqloptomize is a stale .TMM file, so only the next run leads to exactly this bug.

I my description is clear enough to understand the problem.

PS: maybe I should open a new bug for this issue, cause this is not exactly this bug, but leads to it.

Marc,
My apologies, somehow I did not read from your description that you started getting corrupted tables after 5.5=>10.0 upgrade (as the matter of fact, I still don't, maybe it was in some other report?). I do see Phil Sweeney mention it, but the comment is laconic, we'll need more details.
Anyway, getting corrupted tables is indeed a different story, especially if it looks like a regression from a previous version. So yes, please file a new bug report.

Hi Elena,
we switched from mysql 5.1 to Mariad 10.0 all the DB servers (more 100 servers) in 2 months. Now is 2 months that we are all db serves Mariadb 10.0 and we start to have randomly a stale tmm created when optimize run weekly. Thank you

@all: created a new bug for this problem.
@fustini: please comment / describe your problem there, so we get this fixed - hopefully in one of the 10.0 releases so linux distributors push this as an fix to current versions