Server reports memory exhausted on statement prepare

[Arjen Lentz]

Applying this trick: http://openquery.com/blog/cache-preloading-mysqld-startup
(I realise this has been superceded by the XtraDB LRU dump/reload stuff - but since the below occurred and appears to identify a bug, it's useful to report anyway)

It's MariaDB 5.2.7

MariaDB [(none)]> SET SESSION group_concat_max_len=100*1024*1024;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT GROUP_CONCAT(CONCAT('SELECT COUNT(`',column_name,'`) FROM `',table_schema,'`.`',table_name,'` FORCE INDEX (`',index_name,'`)') SEPARATOR ' UNION ALL ') INTO @sql FROM information_schema.statistics WHERE table_schema NOT IN ('information_schema','mysql') AND seq_in_index = 1;
Query OK, 1 row affected (0.15 sec)

MariaDB [(none)]> select length(@sql);
+--------------+
| length(@sql) |
+--------------+
| 869378 |
+--------------+
1 row in set (0.00 sec)

so far so good, resulting SQL query is only 800K long.

MariaDB [(none)]> PREPARE stmt FROM @sql;
ERROR 1064 (42000): memory exhausted near 'INDEX (`PRIMARY`) UNION ALL SELECT COUNT(`id`) FROM `dbname`.`colname' at line 1

It appears (thanks HarrisonF) that the parser runs out of memory? We reckon that'd be a bug.

I'm happy to pass along the entire @sql string, but a) it contains customer details (db/table/col names) so it'd have to be in private and b) the SQL wouldn't run on any other server anyway since the parser would find nonexistent dbs/tables/cols and thus never get to the bug.