Date: Thu, 13 Feb 2014 17:03:06 -0500 From: Ryan Stone <rysto32@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <hackers@freebsd.org>, Vijay Singh <vijju.singh@gmail.com> Subject: Re: Debugging rw lock Message-ID: <CAFMmRNzqL0b5gCC09DbN%2BaJX4ndO9g=y_QKm_6QVXfdvpwOjeg@mail.gmail.com> In-Reply-To: <1392325587.1145.96.camel@revolution.hippie.lan> References: <CALCNsJS6vFJU18F3VRR-T2RdtGNxd3fycUCkQ63BmGp29DAUMw@mail.gmail.com> <52FD30D9.6050604@mu.org> <CALCNsJQzeqGh%2BZ0rW2jw9e%2BDfKdaRo9BpOQq7XrjfZ1EzNDFYQ@mail.gmail.com> <1392325587.1145.96.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 13, 2014 at 4:06 PM, Ian Lepore <ian@freebsd.org> wrote: > Does option DEADLKRES not work with rwlocks? (I've never used it, just > seen it in the NOTES). > > -- Ian DEADLKRES will panic the system after a thread has been blocked for a timeout period (I think that it's something ridiculous like 30 minutes). However it's of no use when trying to debugging a leaked read lock, because the thread that lost the lock will have left behind no clues as to it's identity. If you have some kind of reproduction scenario, the quickest hack that might get you an answer would be to change INP_INFO_RLOCK to actually take a wlock instead. Rather than instrumenting the code, you could use the dtrace lockstat provider to log every lock/unlock and post-process the output to find the culprit. Make sure that you have r258541 if you want to use lockstat. http://svnweb.freebsd.org/changeset/base/258541
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNzqL0b5gCC09DbN%2BaJX4ndO9g=y_QKm_6QVXfdvpwOjeg>