Assertion failure in ext3_sync_file() at fs/ext3/fsync.c:50: "ext3_journal_current_handle() == 0"

[Andreas Dilger]

On Nov 24, 2005  16:42 -0500, linux at horizon.com wrote:
> ------------[ cut here ]------------
> kernel BUG at fs/ext3/fsync.c:50!
> Process aptitude (pid: 26952, threadinfo=c13bc000 task=d99cca80)
> Call Trace:
>  [<b01458ce>] msync_interval+0x8e/0xd0
>  [<b0145a6f>] sys_msync+0x15f/0x171
>  [<b0102c69>] syscall_call+0x7/0xb

This BUG is:
J_ASSERT(ext3_journal_current_handle() == 0);

which means that somehow the aptitude process struct had a journal handle
still active when it shouldn't have.  Are there any console messages or
before the BUG, or just ENOSPC from the program?  Either way, I'd suspect
a bug in the error handling code not doing a journal_stop() before exiting
a function somewhere...

> Here's the tune2fs -l output.  No idea why it says "clean"; it is still
> mounted read/write.
> 
> Filesystem features:      has_journal filetype needs_recovery sparse_super
> Filesystem state:         clean

FYI - all ext3 filesystems say "clean" all the time, because when the
journal replay is completed (note "needs_recovery" flag above) the
filesystem will in fact be clean (i.e. not needing an e2fsck).  If this
were "error" (after the kernel detected some on-disk error) then you'd
get a full e2fsck on boot regardless of ext3 recovery or not.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.