From: FFADO <ffa...@ff...> - 2011-06-18 10:56:24
|
#306: jackd segfaults while terminating when using the Juju stack -----------------------+---------------------------------------------------- Reporter: koniu | Owner: Type: bug | Status: reopened Priority: major | Milestone: Component: generic | Version: FFADO 2.0.1 Resolution: | Keywords: Device_name: | -----------------------+---------------------------------------------------- Comment (by jwoithe): I'll take a look at the logs in a moment. To answer Stefan's question about the structure in disable(), it looks a little odd but it should be fine. It's written like that to permit the printing of the more detailed log messages. One could for instance simply call pthread_mutex_lock(), but then there's no way to determine whether there was lock contention or not. This way we find out. To answer your question, I don't believe it's possible - in these circumstances - to have the lower section execute without the lock. According to the documentation for pthread_mutex_trylock(), the usual return values are 0 (no error, the lock was taken) and EBUSY (the lock is already held and thus cannot be taken). Other errors will not apply: EINVAL requires that the lock is not initialised (the mutex is always initialised by the time disable() is called), and EAGAIN requires that too many recursive locks are held (recursive locking is not configured for this mutex). So unless there's undocumented behaviour occuring in pthread_mutex_trylock() I can't see how the function could continue without the lock held. However, I don't profess to be an expert in the area of posix locks; are you (Stefan) aware of other returns from pthread_mutex_trylock() which aren't in the documentation? "have_lock" is used just because I'm paranoid and don't want to complicate things by calling pthread_mutex_unlock() unless we definitely have the lock. As outlined above though the expectation is that we must always have it by then. I guess to prove this you could comment out the "if (i == EBUSY)" conditional and replace it with a simple "{". That would force the call to pthread_mutex_lock() on ANY error from pthread_mutex_trylock() and answer the question pretty much immediately. I'd have to wait for "roos" to try that though, since I no longer get the double-free on my system (which is running 2.6.39 for reference). -- Ticket URL: <http://subversion.ffado.org/ticket/306#comment:10> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |