Re: memory corruption in recent -current?

Kris Kennaway wrote this message on Sun, Jan 22, 2006 at 15:12 -0500:
> On Sun, Jan 22, 2006 at 11:41:29AM -0800, John-Mark Gurney wrote:
> > I've been working on a BT878 audio driver (first crack is available
> > in p4), and with a recent -current (you can sync to my -current as
> > it's the one in my workspace, jmg_carbon), I get memory corruption:
> > Memory modified after free 0xc2fb1050(12) val=1c _at_ 0xc2fb1050
> > panic: Most recently used by ioctlops
> > or:
> > Memory modified after free 0xc2ba2b90(12) val=1c _at_ 0xc2ba2b90
> > panic: Most recently used by Unitno
> > 
> > I went back to a kerenl that is pre-Dec 21st, and I haven't had a single
> > panic yet.  I will admit I haven't done a builtworld between the these
> > two (the last buildworld matched with the pre-Dec 21st kernel)...  I am
> > using kld modules for my testing, so I was building modules against an
> > old world, but I don't know of anything that has changed that would
> > cause problems..
> > 
> > Anyone else seeing this?
> 
> Use memguard to track down the cause.

Well, looks like memguard is broken?  I just ran it, and got this
panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x800
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc0611c46
stack pointer           = 0x28:0xd1d36c28
frame pointer           = 0x28:0xd1d36c3c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 868 (bktrautest)
[thread pid 868 tid 100088 ]
Stopped at      memguard_free+0x12:     movl    $0xd34dc0d3,0x800(%esi)
db> tr
Tracing pid 868 tid 100088 td 0xc3916820
memguard_free(2e,e,80044105,4,d1d36c80) at memguard_free+0x12
free(2e,c06d4360,2e,2e,0) at free+0x27
ioctl(c3916820,d1d36d04,c3916820,0,2) at ioctl+0x272
syscall(3b,3b,3b,2804fa28,bfbfe8c8) at syscall+0x27e
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28131e53, esp = 0xbfbfe6ec, ebp = 0xbfbfe828 ---

ok, the backtrace:
#11 0xc064a9fa in calltrap () at ../../../i386/i386/exception.s:137
#12 0xc0611c46 in memguard_free (addr=0x0) at ../../../vm/memguard.c:272
#13 0xc04eb2df in free (addr=0x2e, mtp=0xc06d4360)
    at ../../../kern/kern_malloc.c:356
#14 0xc051c98a in ioctl (td=0xc3916820, uap=0xd1d36d04)
    at ../../../kern/sys_generic.c:589
#15 0xc065e296 in syscall (frame=
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 671414824, tf_esi = -1077942072, tf_ebp = -1077942232, tf_isp = -774673052, tf_ebx = 6, tf_edx = 6, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 672341587, tf_cs = 51, tf_eflags = 662, tf_esp = -1077942548, tf_ss = 59})
    at ../../../i386/i386/trap.c:1008
#16 0xc064aa4f in Xint0x80_syscall () at ../../../i386/i386/exception.s:190

It's wierd that free is free'ing an address of 0x2e, and it looks like
the copyin faulted w/ EFAULT probably because of the bad address in
kernel space, not userland... though the memory address shouldn't be
invalid, as the size (4) should of been allocated by:
580                     memp = malloc((u_long)size, M_IOCTLOPS, M_WAITOK);

and should of waited as necessary...  Comments anyone?  I have the dump
around if anyone needs more information.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."