accessing information_schema.INNODB_BUFFER_POOL_CONTENT creashes server when skip-innodb is enabled in 5.0.87-d10-ourdelta65-log

# grep skip-innodb /etc/mysql/my.cnf
skip-innodb

# mysql information_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.0.87-d10-ourdelta65-log (OurDelta - http://ourdelta.org/)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * FROM INNODB_BUFFER_POOL_CONTENT;
ERROR 2013 (HY000): Lost connection to MySQL server during query

in error log:

101013 13:32:36 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=671088640
read_buffer_size=1048576
max_used_connections=837
max_connections=1024
threads_connected=27
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1703936 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x76903450
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xc15ec4f8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81c1026
0x828a6f2
0x82a480d
0x82a4320
0x822995a
0x82263db
0x822b4b6
0x81d83d1
0x81de86d
0x81e12db
0x81e2c01
0xf7ee44c0
0xf7cf66de
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x4ac3b018 is invalid pointer
thd->thread_id=191513426
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Resolved stack dump:

0x81c1026 handle_segfault + 806
0x828a6f2 _Z30innodb_I_S_buffer_pool_contentP3THDP10TABLE_LIST + 18
0x82a480d _Z22fill_innodb_bp_contentP3THDP10TABLE_LISTP4Item + 45
0x82a4320 _Z24get_schema_tables_resultP4JOIN23enum_schema_table_state + 416
0x822995a _ZN4JOIN4execEv + 2618
0x82263db _Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select + 219
0x822b4b6 _Z13handle_selectP3THDP6st_lexP13select_resultm + 326
0x81d83d1 _Z21mysql_execute_commandP3THD + 4113
0x81de86d _Z11mysql_parseP3THDPKcjPS2_ + 1277
0x81e12db _Z16dispatch_command19enum_server_commandP3THDPcj + 3579
0x81e2c01 handle_one_connection + 3169
0xf7ee44c0 _end + -276641592
0xf7cf66de _end + -278664474

Te workaround is to disable skip-innodb in my.cnf