Re: Panic: Memory modified after free

On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote:
> On Tue, Feb 01, 2005 at 08:11:57PM -0500, Bosko Milekic wrote:
> > 
> > I made the attached patch for scottl to allow for > PAGE_SIZE
> > allocations, please feel free to try it as I don't think he has had a
> > chance to yet.
> 
> I had to apply part of the patch by hand, and increase
> MAX_PAGES_PER_ITEM to 128 to deal with M_INODEDEP allocations (well,
> it was asking for at least 64 pages worth, so this may have been a
> factor of 2 overkill).  I don't know if this is correct - it seems
> like a lot of memory to be allocating since all of the allocations I
> could see seem to be for only a single copy of struct inodedep, which
> is nowhere near that big.
> 
> Anyway, it panicked shortly after starting to exercise the FS, with:
> 
> login: panic: mutex  not owned at ../../../vm/vm_page.c:301
> cpuid = 1
> KDB: enter: panic
> [thread pid 717 tid 100147 ]
> Stopped at      kdb_enter+0x30: leave
> db> tr
> Tracing pid 717 tid 100147 td 0xc7f27a10
> kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30
> panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e

From another copy of the same panic:

panic(c06fb4a2,c81a9c10,c071204f,12d,c46b8a28) at panic+0x13e

> 0xc81a9c00:     c81a9c10        c5acb000        deadc0de        c073a160
> 0xc81a9c10:     0               c62df000        deadc0de        c073c560
> 0xc81a9c20:     c82cc110        c5acf000        deadc0de        c073a160
> 0xc81a9c30:     deadc0de        deadc0de        deadc0de        c073c560
> 0xc81a9c40:     deadc0de        deadc0de        deadc0de        c073a160

It looks like the vm object has been freed?

Kris

> _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c
> vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d
> vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3
> trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166
> trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc063af4a, esp = 0xeeca0b44, ebp = 0xeeca0b60 ---
> inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143
> softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softdep_change_linkcnt+0x4f
> ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153
> ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60
> VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78
> kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186
> unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22
> syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (10, FreeBSD ELF32, unlink), eip = 0x280c5b63, esp = 0xbfbfec2c, ebp = 0xbfbfec58 ---
> 
> I don't know if this is a memguard bug or a FreeBSD bug.
> 
> Kris