Re: [TESTCASE] Re: panic when invoking recvfrom
Re: [TESTCASE] Re: panic when invoking recvfrom
- Subject: Re: [TESTCASE] Re: panic when invoking recvfrom
- From: Adi Masputra <email@hidden>
- Date: Fri, 27 Jul 2007 12:53:24 -0700
On Jul 27, 2007, at 12:43 PM, Mark Rhoads wrote:
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?
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
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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