] 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?


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

        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
                                        [EMAIL PROTECTED]
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to