m_freem detected a mbuf double-free : xl0 kernel panic

[Terry Lambert]

Matt wrote:
> Unfortunatly this machine does not have enough swap space to dump a panic
> and I also do not have a serial console so there is no debug information,
> but I am getting a 100% reproducable panic on a kernel built on sources
> cvsup'd either an hour ago or yesterday morning (I've tried both). Sources
> from friday are fine.

makeoptions     DEBUG=-g                #Build kernel with gdb(1) debug symbols
options         DDB                     #Enable the kernel debugger


> The important looking parts I scribbled down on some paper from ddb are
> m_freem detected a mbuf double-free, kernel trap 12 with interrupts
> disabled, current process int12: xl0.
> 
> This happens the second my irc client tries to connect to an irc server
> after booting the system. If I boot kernel.old (from friday) it works
> fine.
> 
> Hopefully somebody else with a nic using the xl driver has the same
> problem and could offer some proper debug. If not I will try and add more
> swap space so I can get a core file.

Look elsewhere; the if_xl.c/if_xlreg.h hasn't been modified for
over 13 days, so it's not an if_xl.c specific problem that came
in last Friday.  Probably you had not updated for a while (if it's
really an if_xl problem -- and you need to tell us how old your
tree was), or it's a problem that was introduced elsewhere, and
happened to bite you in the if_xl.c code.  I expect that this is
the case.  You should look for changed files.

Actually, I think it's rev 1.47 of /src/sys/kern/subr_mbuf.c;
I don't actually see where the M_FREELIST flag is ever cleared
on allocation... might want to send an email to silby at .

Alternately, if it is cleared on allocation somewhere I'm not
seeing, it may be a revealed by in the if_xl driver... or some
place else in the protocol stack, where it's freeing the mbuf,
and then continuing to use it.  I remember a case in the ipfw
code, at one point, where it would do that on "reject" rules,
and then corrupt the heck out of the kernel stack.  8-(.

-- Terry