----- Original Message -----
> On Sat, 2012-10-13 at 01:22 -0400, Nathan Scott wrote:
> > Hi Ken,
> >
> > I came across what looks like a threading-related deadlock
> > while running QA earlier, keen to hear your thoughts. ...
>
> Both pmlogger and pmlc are single-threaded (unless there is some
> under
> the covers multi-threading in pmlogger as a consequence of the timer
> handling), and __pmLock_libpcp is a recursive lock so the only way
> that
> I know this could block is if we had unbounded lock recursion and ran
> into some implementation maximum locking depth in the pthread_mutex
> implementation.
Or a missed unlock call somewhere, on some unusual code path?
> We had a case like this before in pmlogger but that related to the
> per
> context locks (which are also recursive) and this was fixed in commit
> 29d91a.
>
> Commit de185c6 added code to detect lock recursion, but it needs to
> be manually compiled into libpcp.
I'll enable that and see if I can hit it again. It is likely to be
a race (perhaps interestingly, that pmlogger code is in the sigalarm
handler, may be a clue) ... I've done alot of testing on this machine
with this code and hadn't come across this to date.
> I'll take a look when I get a chance.
Thanks.
--
Nathan
|