OK, so this is rather nasty,  in PS 5.5.28:

btr0cur.c:btr_pessimistic_insert(1578) calls fsp_reserve_free_extents to reserve enough real database pages, expanding the space if necessary, to perform the insert.

fsp0fsp.c:fsp_reserve_free_extents(3037) has an unsigned math error when FSP_SIZE is less than FSP_FREE_LIMIT which causes remainder of function to believe that there are an extremely large number of remaining extents, so does not attempt to extend the data file: n_free_up = (size - free_limit) / FSP_EXTENT_SIZE; It returns success without actually extending data file and never detects the quota issue.

So then btr0cur.c:btr_pessimistic_insert(1627) goes on about its businesss, assuming that enough pages have been reserved to perform the insert. The index insertion mechanism _demands_ that pages have already been reserved and has no rational error handling for no space or other page/filesystem errors. 

It then calls:
btr0btr.c:btr_page_split_and_insert(2577) which tries to allocate a page via btr_page_alloc (at line 2666), which fails and returns a NULL (which is never tested for).  Then it calls buf_block_get_page_zip with returned NULL, and asserts.

OK, so, lets fix the math error in fsp_reserve_free_extents by changing line 3037 from:
    n_free_up = (size - free_limit) / FSP_EXTENT_SIZE; 
to:
    if (size <= free_limit) {
        n_free_up = 0; 
    } else if (alloc_type == FSP_UNDO) {
        n_free_up = (size - free_limit) / FSP_EXTENT_SIZE;
    }

OK, so this solves the issue for _small_ inserts, like if the test above just did something like:
    for i in `seq 2000`; do mysql -e 'INSERT INTO free2test.t1(i) VALUES (null)'; done;
But, if we follow the sequence prescribed above by doing:
    mysql -e 'INSERT INTO free2test.t1 SELECT null FROM free2test.t1'

Then we have a big problem. There is no space left to perform the rollback. If we set a simple break point at the end of fsp_reserve_free_extents on  "if (success && n_pages_added > 0)" :
    b fsp0fsp.c:3088 if space > 0 && (!success || !n_pages_added)
This will stop us every time we 'detect' the error...

Here is the call stack where we first detect the space issue:
#0  fsp_reserve_free_extents (n_reserved=0x7fffdf707940, space=10, n_ext=3, alloc_type=1000000, mtr=0x7fffdf7079e0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/fsp/fsp0fsp.c:3105
#1  0x0000000000879ecc in btr_cur_pessimistic_insert (flags=0, cursor=0x7fffdf707ed0, entry=0x7fffd000d668, rec=0x7fffdf707ec8, big_rec=0x7fffdf707ec0, n_ext=0, thr=0x7fffd000cca8, mtr=0x7fffdf7079e0)
    at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/btr/btr0cur.c:1578
#2  0x0000000000960e12 in row_ins_index_entry_low (mode=<value optimized out>, index=0x7fffd0012968, entry=0x7fffd000d668, n_ext=0, thr=0x7fffd000cca8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0ins.c:2190
#3  0x0000000000962681 in row_ins_index_entry (index=0x7fffd0012968, entry=0x7fffd000d668, n_ext=0, foreign=<value optimized out>, thr=0x7fffd000cca8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0ins.c:2294
#4  0x00000000009631c5 in row_ins_index_entry_step (thr=0x7fffd000cca8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0ins.c:2370
#5  row_ins (thr=0x7fffd000cca8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0ins.c:2502
#6  row_ins_step (thr=0x7fffd000cca8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0ins.c:2619
#7  0x0000000000814bf0 in row_insert_for_mysql (mysql_rec=0x7fffd000b740 "\375\215\t", prebuilt=0x7fffd000c2d8) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0mysql.c:1255
#8  0x00000000007f1bec in ha_innobase::write_row (this=0x7fffd0009b10, record=0x7fffd000b740 "\375\215\t") at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/handler/ha_innodb.cc:6006
#9  0x00000000006b1c33 in handler::ha_write_row (this=0x7fffd0009b10, buf=0x7fffd000b740 "\375\215\t") at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/handler.cc:5359
#10 0x000000000058384b in write_record (thd=0x11b60d0, table=0x7fffd0010510, info=0x7fffd00057d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_insert.cc:1788
#11 0x0000000000583bdf in select_insert::send_data (this=0x7fffd0005798, values=...) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_insert.cc:3458
#12 0x00000000005c3e27 in end_send (join=0x7fffd0034dc0, join_tab=<value optimized out>, end_of_records=false) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:12722
#13 0x00000000005bd67d in evaluate_join_record (join=0x7fffd0034dc0, join_tab=0x7fffd0006480, error=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:11934
#14 0x00000000005c6988 in sub_select (join=0x7fffd0034dc0, join_tab=0x7fffd0006480, end_of_records=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:11792
#15 0x00000000005d7b35 in do_select (join=0x7fffd0034dc0, fields=0x7fffd0036408, table=0x0, procedure=0x0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:11552
#16 0x00000000005da2d5 in JOIN::exec (this=0x7fffd0034dc0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:2400
#17 0x00000000005dada5 in mysql_select (thd=0x11b60d0, rref_pointer_array=0x11b8578, tables=0x7fffd0005250, wild_num=0, fields=<value optimized out>, conds=<value optimized out>, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, 
    select_options=3489925888, result=0x7fffd0005798, unit=0x11b7d80, select_lex=0x11b83a0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:2609
#18 0x00000000005de404 in handle_select (thd=0x11b60d0, lex=0x11b7cc0, result=0x7fffd0005798, setup_tables_done_option=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_select.cc:312
#19 0x000000000059b7c1 in mysql_execute_command (thd=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:3140
#20 0x000000000059f050 in mysql_parse (thd=0x11b60d0, rawbuf=0x7fffd0004a20 "INSERT INTO free2test.t1 SELECT null, c FROM free2test.t1", length=<value optimized out>, parser_state=0x7fffdf709af0)
    at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:5811
#21 0x00000000005a036f in dispatch_command (command=COM_QUERY, thd=0x11b60d0, packet=<value optimized out>, packet_length=57) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:1061
#22 0x00000000005a18a9 in do_command (thd=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:788
#23 0x0000000000646ae2 in do_handle_one_connection (thd_arg=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_connect.cc:1484
#24 0x0000000000646bd8 in handle_one_connection (arg=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_connect.cc:1391
#25 0x000000360dc07851 in start_thread () from /lib64/libpthread.so.0
#26 0x000000360d8e811d in clone () from /lib64/libc.so.6

And here is the call stack which where we start failing miserably trying to perform the undo because btr_cur_pessimistic_delete also needs some free space, which doesn't exist:
#0  fsp_reserve_free_extents (n_reserved=0x7fffdf707e98, space=10, n_ext=1, alloc_type=3000000, mtr=0x7fffdf707ef0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/fsp/fsp0fsp.c:3105
#1  0x000000000087d49b in btr_cur_pessimistic_delete (err=0x7fffdf7083c8, has_reserved_extents=0, cursor=0x7fffd0039a90, rb_ctx=RB_NORMAL, mtr=0x7fffdf707ef0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/btr/btr0cur.c:3239
#2  0x000000000097039c in row_undo_ins_remove_clust_rec (node=0x7fffd0039a18) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0uins.c:117
#3  0x00000000009709e5 in row_undo_ins (node=0x7fffd0039a18) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0uins.c:364
#4  0x0000000000966c40 in row_undo (thr=0x7fffd0038a20) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0undo.c:320
#5  row_undo_step (thr=0x7fffd0038a20) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/row/row0undo.c:367
#6  0x0000000000953747 in que_thr_step (thr=0x7fffd000fb50) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/que/que0que.c:1257
#7  que_run_threads_low (thr=0x7fffd000fb50) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/que/que0que.c:1319
#8  que_run_threads (thr=0x7fffd000fb50) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/que/que0que.c:1356
#9  0x00000000008533c6 in trx_general_rollback_for_mysql (trx=0x7fffd0034868, savept=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/trx/trx0roll.c:97
#10 0x0000000000853966 in trx_rollback_for_mysql (trx=0x7fffd0034868) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/trx/trx0roll.c:146
#11 0x00000000007f0eca in innobase_rollback (hton=<value optimized out>, thd=0x11b60d0, all=false) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/storage/innobase/handler/ha_innodb.cc:3677
#12 0x00000000006af2a9 in ha_rollback_trans (thd=0x11b60d0, all=false) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/handler.cc:1541
#13 0x00000000006548ad in trans_rollback_stmt (thd=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/transaction.cc:341
#14 0x000000000059e90c in mysql_execute_command (thd=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:4631
#15 0x000000000059f050 in mysql_parse (thd=0x11b60d0, rawbuf=0x7fffd0004a20 "INSERT INTO free2test.t1 SELECT null, c FROM free2test.t1", length=<value optimized out>, parser_state=0x7fffdf709af0)
    at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:5811
#16 0x00000000005a036f in dispatch_command (command=COM_QUERY, thd=0x11b60d0, packet=<value optimized out>, packet_length=57) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:1061
#17 0x00000000005a18a9 in do_command (thd=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_parse.cc:788
#18 0x0000000000646ae2 in do_handle_one_connection (thd_arg=<value optimized out>) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_connect.cc:1484
#19 0x0000000000646bd8 in handle_one_connection (arg=0x11b60d0) at /home/glorch/dev/ps-5.5-27444-debug/Percona-Server/sql/sql_connect.cc:1391
#20 0x000000360dc07851 in start_thread () from /lib64/libpthread.so.0
#21 0x000000360d8e811d in clone () from /lib64/libc.so.6

There is an OLD MySQL bug somewhat related to this issue http://bugs.mysql.com/bug.php?id=43665.

I need to get with our senior guys to see if there is something more that we can do about it. We may be able to do something like increase the forward-looking extent allocation to 'pad' for any following case of a rollback, or, there may be a more delicate way to perform the pessimistic_delete when we are performing a rollback that doesn't end up requiring more space.