site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jul 27, 2007, at 12:43 PM, Mark Rhoads wrote: This is a known issue (it is not select related). A workaround is to not do MSG_DONTWAIT when multiple threads read from the same socket, or do MSG_DONTWAIT single threaded. Adi --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/adi%40apple.com _______________________________________________ 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 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. This email sent to adi@apple.com smime.p7s