mbuf corruption tracking advice
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Does anybody have any advice about how to track down an mbuf data corruption panic? I'm now able to sometimes reproduce mbuf corruption with my driver/hardware on ppc. It seems to happen most frequently after suspend/resume, but sometimes also happens soon after kextload. In my latest panic, I've got a stack that looks like the following. I was wondering what techniques might be recommended to track this down. I've instrumented my driver, and I'm recording ever mbuf I've seen. I cannot find any evidence my driver has ever even touched the mbuf in question. Obviously I must be causing this somehow though.. Thanks, Drew (gdb) bt #0 Debugger (message=0x30cb04 "panic") at /SourceCache/xnu/xnu-792.12.6/osfmk/ppc/model_dep.c:639 #1 0x00026898 in panic (str=0x32c84c "freeing free mbuf") at /SourceCache/xnu/xnu-792.12.6/osfmk/kern/debug.c:202 #2 0x0028c4ec in m_free (m=0x1dc1e200) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_mbuf.c:600 #3 0x00295558 in sbdroprecord (sb=0x190cb94) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_socket2.c:1181 #4 0x002922c4 in soreceive (so=0x190cb50, psa=0xcfc3dc8, uio=0x1cb4f00, mp0=0x0, controlp=0x1dbbd000, flagsp=0xcfc3e8c) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_socket.c:1924 #5 0x00296f38 in recvit (p=0x18ed0f0, s=9, mp=0xcfc3e60, uiop=0x1cb4f00, namelenp=0, retval=0x16c2108) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_syscalls.c:932 #6 0x0029763c in recvmsg (p=0x18ed0f0, uap=0x16c20c4, retval=0x16c2108) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_syscalls.c:1255 #7 0x002aae28 in unix_syscall (regs=0x3e0000) at /SourceCache/xnu/xnu-792.12.6/bsd/dev/ppc/systemcalls.c:207 #8 0x000ab930 in noassist () #9 0x3e312e30 in ?? () The mbuf itself looks like this: (gdb) frame 2 #2 0x0028c4ec in m_free (m=0x1dc1e200) at /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_mbuf.c:600 600 in /SourceCache/xnu/xnu-792.12.6/bsd/kern/uipc_mbuf.c (gdb) p *m $34 = { m_hdr = { mh_next = 0x1dc1e100, mh_nextpkt = 0x0, mh_len = -1, mh_data = 0xffffffff <Address 0xffffffff out of bounds>, mh_type = 0, mh_flags = -1 }, M_dat = { MH = { MH_pkthdr = { len = -1, rcvif = 0xffffffff, header = 0xffffffff, csum_flags = -1, csum_data = -1, aux = 0xffffffff, vlan_tag = 65535, socket_id = 65535, tags = { slh_first = 0xffffffff } }, MH_dat = { MH_ext = { ext_buf = 0xffffffff <Address 0xffffffff out of bounds>, ext_free = 0xffffffff, ext_size = 4294967295, ext_arg = 0xffffffff <Address 0xffffffff out of bounds>, ext_refs = { forward = 0xffffffff, backward = 0xffffffff } }, MH_databuf = 'y' <repeats 204 times> } }, M_databuf = 'y' <repeats 236 times> } } If I follow the mh_next pointer, the next mbuf looks exactly the same except for the next pointer: (gdb) p *(struct mbuf *)0x1dc1e100 $35 = { m_hdr = { mh_next = 0x1dc1e000, mh_nextpkt = 0xffffffff, <...> And the chain seems to end here: (gdb) p *(struct mbuf *)0x1dc1e000 $36 = { m_hdr = { mh_next = 0x0, mh_nextpkt = 0xffffffff, <....> What would set the data of a bunch of mbufs to all 0xff while preserving their next pointers? Thanks, Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
Andrew Gallatin