site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Organization: WiredRoads User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) I wonder, are both recvfrom's acting upon the same packet when the kernel panics (and thus freeing the mbufs of the same packet)? Or, more generally, is the panic due to a mbuf chain/links getting updated at the same time by two threads (i.e. not only on the packet's mbuf chain, but adding a mbuf to the free mbuf chain)? I agree with previous posts: no user space code should ever be able to cause a panic. However, as a work-around if you cannot wait for a fix, how about giving up the simplicity of having select/recv on the same socket in multiple threads by splitting the code up into one select/recv thread and multiple worker threads that work off of a shared queue? If you're desperate, another approach, though I've never tried this on Darwin, is to perform a 'live patch' of the problematic code (once that code is identified). Such an approach is fraught with compatibility issues, but it can be useful under the right circumstances. I've done this on some other *nixes, but have never had the opportunity on Darwin/OSX. --Mark Rhoads _______________________________________________ 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