Comment 6 for bug 982872

Reproducible on maria-5.2, 5.3, 5.5.

I removed unnecessary tables, but that's about all simplification I was able to perform. The data and aria logs are still big.
3 archive files are uploaded to FTP (in addition to what Dreas provided before):

982872_datadir.tar.gz - already created and populated table and offending aria logs placed into the datadir. To reproduce the problem, decompress the archive and start MariaDB server on the extracted 'data' as a datadir (or run aria_read_log -a inside the datadir).

982872_aria_logs.tar.gz - separately archived aria logs.
982872_sql.tar.gz - the dump of the table (structure and data).
To reproduce the problem using the dump, create a new empty datadir, start MariaDB server, load the dump, shutdown the server, place aria logs into the resulting datadir, then either start the server or run aria_read_log -a.

On release server, it crashes as described above.
On 5.2 debug server it aborts with the failing assertion:

[Note] mysqld: Aria engine: starting recovery
recovered pages: 0%mysqld: ma_blockrec.c:6355: _ma_apply_redo_insert_row_head_or_tail: Assertion `!new_page' failed.

#6 0x00007fe752c3bd4d in __GI___assert_fail (assertion=0xdb8d72 "!new_page", file=<optimized out>, line=6355,
    function=<optimized out>) at assert.c:81
#7 0x0000000000a0f72a in _ma_apply_redo_insert_row_head_or_tail (info=0x25f0708, lsn=42966603572, page_type=1,
    new_page=1 '\001', header=0x25e1cda "\236", <incomplete sequence \372>, data=0x25e1ce0 "", data_length=34)
    at ma_blockrec.c:6355
#8 0x00000000009c9ba8 in exec_REDO_LOGREC_REDO_INSERT_ROW_HEAD (rec=0x7fff100855f0) at ma_recovery.c:1537
#9 0x00000000009c7619 in display_and_apply_record (log_desc=0x1a662b8, rec=0x7fff100855f0) at ma_recovery.c:587
#10 0x00000000009ccd30 in run_redo_phase (lsn=42966567214, lsn_end=0, apply=MARIA_LOG_APPLY) at ma_recovery.c:2695
#11 0x00000000009c6ec6 in maria_apply_log (from_lsn=42966567214, end_lsn=0, apply=MARIA_LOG_APPLY, trace_file=0x25e1a00,
    should_run_undo_phase=1 '\001', skip_DDLs_arg=1 '\001', take_checkpoints=1 '\001', warnings_count=0x7fff10085b08)
    at ma_recovery.c:349
#12 0x00000000009c6b44 in maria_recovery_from_log () at ma_recovery.c:239
#13 0x0000000000956b2f in ha_maria_init (p=0x25c7718) at ha_maria.cc:3366
#14 0x00000000007d2209 in ha_initialize_handlerton (plugin=0x25c6cf0) at handler.cc:432
#15 0x00000000008a361a in plugin_initialize (plugin=0x25c6cf0) at sql_plugin.cc:1263
#16 0x00000000008a3c88 in plugin_init (argc=0x1246a78, argv=0x25988e0, flags=0) at sql_plugin.cc:1451
#17 0x0000000000680146 in init_server_components () at mysqld.cc:4089
#18 0x0000000000680cb9 in main (argc=8, argv=0x7fff100863f8) at mysqld.cc:4560

aria_read_log -a (debug version) also aborts with an assertion:

aria_read_log: ma_key_recover.c:988: _ma_apply_redo_index: Assertion `page_offset >= keypage_header && page_offset <= page_length' failed.

A release version of aria_read_log -a crashes with segmentation fault.