Date: Tue, 5 Jun 2001 20:09:14 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: current@freebsd.org Cc: mjacob@feral.com Subject: Re: anyone seen these outside of alpha? or on non-SMP? Message-ID: <200106052010.NAA29251@usr01.primenet.com>
next in thread | raw e-mail | index | archive | help
] Data modified on freelist: word 2 of object 0xfffffe000190b780 size 72 ] previous type inodedep (0xd6adc0de != 0xdeadc0de) ] ... ] Data modified on freelist: word 2 of object 0xfffffe0001806700 size 72 ] previous type pagedep (0xd6adc0de != 0xdeadc0de) ] ] ] Anyone seen these on non-SMP? On i386? Yes. I have seen this on 4.3, after opening more than 32,767 network connections, only in my case the problem occurred in the close, after the credential structure reference count overflowed. There will probably be significantly more of these problems in -current, since much of the recent locking work has been a bit less than comprehensive, so there are probably free races in a lot of places that used to be implicitly protected via past serialization through the BGL. There are exactly 12 structures 72 bytes long in the FreeBSD kernel: struct rusage= 72 struct nameidata= 72 struct ifpppstatsreq = 72 struct ifpppcstatsreq = 72 struct sadb_comb = 72 struct ddpcb = 72 struct atmsetreq = 72 struct linkinfo = 72 struct ng_one2many_config = 72 struct ng_ppp_mp_state = 72 struct ipfw_dyn_rule = 72 struct secasvar = 72 Despite the obvious involvement os the soft updates code (there is a reference counted object reference underflow, which resulted in the data being in use after nominally being freed), my money is on the "struct rusage" on a process exit. This implies a race condition in the sync'ing of data for files being resource-tracking closed as a result of the process exit triggering a dependency failure. My guess would be that the inode in question is a directory inode, and that there are temp files there, or a lot of open files, but that is just a ballpark guess. -- My first suggestion would be to turn the printf() as a result of INVARIANTS (which is where the message is coming from, in the kern_malloc.c code) into a true panic, since what you are seeing isundoubtedly a cascade failure. This will (if you have the debugger enabled) let you examine the object that is being spam'med before it gets stepped on into illegibility. Knowing the size will let you catch the allocation. -- Note that in the message referenced by David, the errors were on different objects; I'll guess at decoding them, as well: May 27 18:52:06 xor /boot/kernel/kernel: Data modified on freelist: word 2 of object 0xc1a60100 size 64 previous type pagedep (0xd6adc0de != 0xdeadc0de) May 27 18:52:06 xor /boot/kernel/kernel: Data modified on freelist: word 2 of object 0xc16f02c0 size 64 previous type pagedep (0xd6adc0de != 0xdeadc0de) May 27 18:52:06 xor /boot/kernel/kernel: Data modified on freelist: word 2 of object 0xc1a60480 size 52 previous type pagedep (0xd6adc0de != 0xdeadc0de) ...these are 64 and 52 bytes each -- different structures. Here are the probables: struct iodone_chain= 52 struct lockf= 52 struct protosw= 52 struct attr_calling = 52 struct ng_bpf_hookprog = 52 struct mrtstat = 52 struct ipprotosw = 52 struct udpstat = 52 struct ip6protosw = 52 struct ostat= 64 struct ifaliasreq = 64 struct at_aliasreq = 64 struct attr_traffic = 64 struct atm_sock_stat = 64 struct ng_type = 64 struct ng_pptpgre_stats = 64 struct in_aliasreq = 64 struct in6_prefixreq = 64 struct ip6_pktopts = 64 ...my ballpark bets, again, would be: struct lockf= 52 struct ostat= 64 Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106052010.NAA29251>