In fact it's a much more interesting problem. What happened was that
you got unlucky and trash got written into your inode table. One of
the inodes that got overwritten had the directory bit set, and the
extents flag was not set. So the i_blocks field was interpreted as
a series of blocks. Many of those i_blocks entries were garbage, and
were cleared, but the triple indirect block could be interpreted as a
valid block number, so we started iterating over all of the double
indirection blocks. To make sure that the directory doesn't have
"holes" in it, e2fsck then started allocating entries to keep track of
all of this via ext2fs_add_dir_block2(), and this is what caused the
memory overflow.
To fix this what we need to do is to notice when an inode looks
insane, and ask the user if they are willing to just nuke it, as
opposed to trying to fix all of the individual things that are wrong
with it.
The way to work around this problem should it occur again is to note
the inode number, and then zap it using debugfs:
debugfs -w /dev/md1
debugfs: clri <169246423>
debugfs: quit
Then e2fsck should be able to complete its work.
