Re: kernel panic - freeing free mbuf
Re: kernel panic - freeing free mbuf
- Subject: Re: kernel panic - freeing free mbuf
- From: Michael Cashwell <email@hidden>
- Date: Fri, 19 Aug 2005 14:26:13 -0400
On Aug 19, 2005, at 12:51 PM, Russell Seehafer (RIT Student) wrote: I have modified the apple example code for the tcplognke kernel extension (10.4 version) to selectively swallow packets, pass information to a user process and re-inject each packet (or drop it) when it recieves a response back from the user process (they communicate on a control socket). I swallow and re-inject each packet the same as in the tcplognke example (except my user process directs the re-injection, not a timer). I also use the same structures and queue's to hold the swallowed packets. The program works great for a while then I get a "freeing free mbuf" kernel panic. For the life of me I cannot figure out how I could have a reference to a free'd mbuf in my code. I have a routine that flushes the queue for a given socket (drops the data - does not re-inject) that is called when I recieve certain events on that socket (disconnecting, disconnected, closing, shutdown, cantrecmore, and cantsendmore ). Using the backtrace in the panic dump I can tell that it happends when I recieve a socket closing event and I flush the queue. If I remove the calls to the flush routine the same kernel panic is caused by my re-inject routine ( I free the packet if the sock_inject_data_out fails ). Any input or direction as to how I could have a reference to a free'd mbuf would be greatly appreciated!
-Russ
Are you holding and then selectively allowing or dropping only outbound packets (from the system heading out to the network) or are you also doing this with inbound packets too? If the latter can you say anything about whether the failures are always out or in? Your description sounds like it only outbound packets that are at issue, but I figured I'd ask.
The place I'd look first is your return code you give back to the kernel when it hands you a packet that it wants to transmit. There are two degrees of freedom here. One is whether or not an error is being declared and the other is whether or not the packet is being consumed. These two things are independent so some degree. (I'd have to go study the interfaces to say more, but you should look for the particulars around the EJUSTRETURN result.)
It sounds like you are returning something to the kernel when it hands you a packet that makes it think it still has ownership of it. It then reuses the buffer or frees it and later you either free it or reinject it (in which case the driver free it after it's sent). Either way this would constitute a double-free.
You need to make certain that what you return to the kernel indicates that you are claiming ownership of the buffer in all cases. That way you can decide what to do with it later. Since you say it happens in response to the socket closing. Presumably then you have packets held and must deal with them. Verify that your handling of these packets is consistent with the return code you gave the kernel when you got the packet.
Good luck!
-Mike
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden