Sorry, I should specify that this is an Aria table and is supposed to be an Aria table. It was, about a year ago, converted to Aria from MyISAM. I haven't done too much investigation into what version of MariaDB might have been used at the time or anything like that...

ALTER TABLE ... ENGINE=ARIA; seems to fix this and put the correct engine ID (0x2a) into the .frm file.

Modifying the 4th byte to 0x2b on a MyISAM table does exactly the same : works as if nothing were wrong on MariaDB 5.5.32 but crashes on 5.5.33.

Here is what i got on 5.5.33 if i try to do a SELECT on the table or a SHOW TABLE STATUS (i can do both without any error on the logs on 5.5.32) :
mysqld: Version: '5.5.33-MariaDB-1~squeeze' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution
mysqld: 130918 3:10:45 [ERROR] mysqld: Incorrect information in file: './test123/zz_comments.frm'
mysqld: 130918 3:10:45 [ERROR] mysqld got signal 11 ;
mysqld: This could be because you hit a bug. It is also possible that this binary
mysqld: or one of the libraries it was linked against is corrupt, improperly built,
mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
mysqld:
mysqld: To report this bug, see http://kb.askmonty.org/en/reporting-bugs
mysqld:
mysqld: We will try our best to scrape up some info that will hopefully help
mysqld: diagnose the problem, but since we have already crashed,
mysqld: something is definitely wrong and this may fail.
mysqld:
mysqld: Server version: 5.5.33-MariaDB-1~squeeze
mysqld: key_buffer_size=2147483648
mysqld: read_buffer_size=2097152
mysqld: max_used_connections=1
mysqld: max_threads=252
mysqld: thread_count=1
mysqld: It is possible that mysqld could use up to
mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 3133826 K bytes of memory
mysqld: Hope that's ok; if not, decrease some variables in the equation.
mysqld:
mysqld: Thread pointer: 0x0x7fd4e71ee680
mysqld: Attempting backtrace. You can use the following information to find out
mysqld: where mysqld died. If you see no messages after this, something went
mysqld: terribly wrong...
mysqld: stack_bottom = 0x7fd1c29cfe58 thread_stack 0x48000
mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7fd4dbbe280e]
mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x4ac)[0x7fd4db7e1d7c]
mysqld: /lib/libpthread.so.0(+0xeff0)[0x7fd4daedeff0]
mysqld: /usr/sbin/mysqld(_ZN11TABLE_SHARE7destroyEv+0x9d)[0x7fd4db72368d]
mysqld: /usr/sbin/mysqld(my_hash_delete+0x314)[0x7fd4dbbc74d4]
mysqld: /usr/sbin/mysqld(+0x32d6c8)[0x7fd4db6396c8]
mysqld: /usr/sbin/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0x6d7)[0x7fd4db642ee7]
mysqld: /usr/sbin/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x59d)[0x7fd4db6443bd]
mysqld: /usr/sbin/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTjj+0x4f)[0x7fd4db64501f]
mysqld: /usr/sbin/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x29)[0x7fd4db6e5119]
mysqld: /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19b9)[0x7fd4db68eab9]
mysqld: /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x419)[0x7fd4db753809]
mysqld: /usr/sbin/mysqld(handle_one_connection+0x51)[0x7fd4db7538c1]
mysqld: /lib/libpthread.so.0(+0x68ca)[0x7fd4daed68ca]
mysqld: /lib/libc.so.6(clone+0x6d)[0x7fd4d9855b6d]
mysqld:
mysqld: Trying to get some variables.
mysqld: Some pointers may be invalid and cause the dump to abort.
mysqld: Query (0x7fd4e7239a18):
mysqld:
mysqld: Connection ID (thread ID): 1
mysqld: Status: NOT_KILLED
mysqld:
mysqld: Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off

ps: i used the same table structure as the original crashing .frm for my test : http://paste.karbowiak.dk/84e86c5921f0eb3ede3d427295e4dd421bfbb0a2/

If you want to check that you don't have one of these frm file with a bad value (don't forget to adjust to your datadir if its not /var/lib/mysql/) :
for frm in /var/lib/mysql//.frm; do [[ "$(od -An -j2 -N2 -x "$frm")" = " 2b0a" ]] && echo "$frm"; done

It will return a list of frm files that has this DB_TYPE then if the tables are Aria ones, you will hit the bug.

For the record:

• before Aria engine type code was frozen in MDEV-4466 it was dynamic and when OQGraph of Sphinx is compiled statically (they also have dynamic engine codes), Aria could've had not 0x2a, but 0x2b or even 0x2c
• after MDEV-4466 Aria always has 0x2a
• after MDEV-4507 TokuDB has 0x2b (it cannot have dynamic code because of MDEV-4466)
• now the server refuses to load frms that have engine code 0x2b (TokuDB) and the engine name "Aria"

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/4041