Comment 2 for bug 582035

I talked with psusi (Phillip Susi) in #ubuntu-devel and he seemed to have some interesting ideas, unfortunately I had absolutely no idea what he was talking about (me not knowing the code, or any theory of filesystems at all), so I though I would post it here for reference by others.

Main points (edited):

Sounds like an assertion failure triggered by the sigint... search the code for that string.
Sounds like the canceling tries to do some cleanup in the SIGINT handler, and part of that cleanup is trying to write out the inode allocation bitmap, which an assertion check makes sure is actually loaded first and it isn't.
It may not be loaded either because it has not been loaded yet at the time of the SIGINT, or because that block group's inode allocation bitmap is uninitialized.

First thing I'd do is search the source code for the string "Inode bitmap not loaded while"
My guess is you will find an assert() with that string in it and that assertion is failing because of a race condition in which the inode allocation bitmap is not loaded yet, but should be eventually... and that could be a little tricky to fix.

But I have a feeling that probably it is not loaded because that block group's inode table is uninitialized in the first place.. meaning there are no inodes used in that block group so the allocation table is not actually valid and a flag says it is unused, assume it's all empty.

Fixing that should be as simple as putting in a check for the uninitialized flag in the code trying to flush the allocation bitmap and bail out of it is set.

/lastlog attached for completeness