linux at horizon.com
2005-Nov-24 21:42 UTC
Assertion failure in ext3_sync_file() at fs/ext3/fsync.c:50: "ext3_journal_current_handle() == 0"
------------[ cut here ]------------
kernel BUG at fs/ext3/fsync.c:50!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<b0187d38>] Not tainted VLI
EFLAGS: 00010296 (2.6.13.1)
EIP is at ext3_sync_file+0x58/0xf0
eax: 00000068 ebx: bf4a479c ecx: b03cffac edx: b03cffac
esi: b0398cfc edi: b2b8f1c8 ebp: c13bcf60 esp: c13bcf18
ds: 007b es: 007b ss: 0068
Process aptitude (pid: 26952, threadinfo=c13bc000 task=d99cca80)
Stack: b0398afc b0383f40 b0395746 00000032 b0398cfc 00000000 00000000 e84824c0
ca281dc0 bf4a483c c13bcf60 b01317c2 bf4a483c 00000000 00000000 e84824c0
ffffffe4 bf4a483c c13bcf80 b01458ce e84824c0 dce74d9c 00000001 a7004000
Call Trace:
[<b01032cb>] show_stack+0xab/0xf0
[<b0103494>] show_registers+0x164/0x200
[<b01036a8>] die+0xc8/0x150
[<b01037b9>] do_trap+0x89/0xd0
[<b0103b1a>] do_invalid_op+0xaa/0xc0
[<b0102eef>] error_code+0x4f/0x54
[<b01458ce>] msync_interval+0x8e/0xd0
[<b0145a6f>] sys_msync+0x15f/0x171
[<b0102c69>] syscall_call+0x7/0xb
Code: ba 46 57 39 b0 be fc 8c 39 b0 b8 40 3f 38 b0 89 74 24 10 89 4c 24 0c 89 54
24 08 89 44 24 04 c7 04 24 fc 8a 39 b0 e8 08 10 f9 ff <0f> 0b 32 00 46 57
39 b0 0f b7 43 28 25 00 f0 00 00 3d 00 80 00
x86, uniprocessor, 2.6.13.1, ext3 file system, data=ordered, 6-way RAID-1.
Kernel is stock except for ppskit-lite patches.
This is the usually-not-mounted emergency rescue partition which
contains disaster recovery tools. Thus, the somewhat paranoid
data integrity settings.
The FS just filled up as I was doing the every-few-months update.
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md1 432312 425732 0 100% /boot
I'm currently copying a raw device snapshot which I can make available to
anyone who promises not to go grepping for secrets on it. I don't think
there are any, but hunting through the whole image and maybe zeroing a
few data blocks is a bit of a PITA.
Anyway, thanks for what has usually been a very reliable file system!
I hope there's enough info here to find the problem.
Here's the tune2fs -l output. No idea why it says "clean"; it is
still
mounted read/write.
tune2fs 1.38 (30-Jun-2005)
Filesystem volume name: <none>
Last mounted on: /boot
Filesystem UUID: ad036960-f1df-4c5e-9240-4e917527f20c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Remount read-only
Filesystem OS type: Linux
Inode count: 55296
Block count: 439360
Reserved block count: 21968
Free blocks: 91538
Free inodes: 30975
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1024
Inode blocks per group: 128
Last mount time: Thu Nov 24 20:52:16 2005
Last write time: Thu Nov 24 20:52:16 2005
Mount count: 6
Maximum mount count: 34
Last checked: Sat Aug 6 04:39:08 2005
Check interval: 15552000 (6 months)
Next check after: Thu Feb 2 04:39:08 2006
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Journal backup: inode blocks
Christian
2005-Nov-26 22:44 UTC
Assertion failure in ext3_sync_file() at fs/ext3/fsync.c:50: "ext3_journal_current_handle() == 0"
On Thu, November 24, 2005 22:42, linux at horizon.com wrote:> ------------[ cut here ]------------ > kernel BUG at fs/ext3/fsync.c:50! > invalid operand: 0000 [#1] > CPU: 0is this error reproducible?> Here's the tune2fs -l output. No idea why it says "clean"; it is still > mounted read/write.i don't know if this is "ok" (don't have the docs atm) but does e2fsck report anything to worry about? thanks, Christian -- make bzImage, not war
Andreas Dilger
2005-Nov-27 09:00 UTC
Assertion failure in ext3_sync_file() at fs/ext3/fsync.c:50: "ext3_journal_current_handle() == 0"
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/0xbThis 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: cleanFYI - 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.