Re: [TESTCASE] Re: panic when invoking recvfrom
Re: [TESTCASE] Re: panic when invoking recvfrom
- Subject: Re: [TESTCASE] Re: panic when invoking recvfrom
- From: Mark Rhoads <email@hidden>
- Date: Fri, 27 Jul 2007 12:43:48 -0700
- Organization: WiredRoads
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden