pthread_mutex_lock_full Assertion

Linux
1

I am porting some Juce code to Linux that works great in Windows. I am having some issues with the code hanging periodically at ScopedLock. Also, I eventually get a __pthread_mutex_lock_full assertion failure in pthread_mutex_lock.c (line 309) - ‘(-(e)) != 35 || (kind != PTHREAD_MUTEX_ERRORCHECK_NP && kind != PTHREAD_MUTEX_RECURSIVE_NP)’.

As I said, this code works fine in Windows. Any ideas why the ScopedLock would act differently in Linux?

Thanks!

Note: Using latest version of Ubuntu.

Here is the code in Linux where the assertion fails…

            if (INTERNAL_SYSCALL_ERROR_P (e, __err)
                 && (INTERNAL_SYSCALL_ERRNO (e, __err) == ESRCH
                     || INTERNAL_SYSCALL_ERRNO (e, __err) == EDEADLK))
               {
                 assert (INTERNAL_SYSCALL_ERRNO (e, __err) != EDEADLK
                         || (kind != PTHREAD_MUTEX_ERRORCHECK_NP
                            && kind != PTHREAD_MUTEX_RECURSIVE_NP));
                 /* ESRCH can happen only for non-robust PI mutexes where
                   the owner of the lock died.  */
                 assert (INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust);

                 /* Delay the thread indefinitely.  */
                 while (1)
                 pause_not_cancel ();
             }
2

Never seen that one before… Can you give me some code that I could use to reproduce it?

3

I’ll see what I can put together. It’s part of a very large project with many pieces working together and interacting with hardware over firewire. Let me see if I can reproduce it on a smaller scale example. By the way, do you know what the maximum of locks in a PTHREAD_MUTEX_RECURSIVE lock is - I keep seeing documentation that says there is a maximum but have never seen that value. Thanks.

4

Is there a maximum? I would have thought it just contained a counter for the recursion depth, rather than having a finite number of slots.

5

That’s what I thought, but I found the statement below here - http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_lock.html

[EAGAIN]
[XSI] The mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded.

 The functionality described is an XSI extension. Functionality marked XSI is also an extension to the ISO C standard. Application writers may confidently make use of an extension on all systems supporting the X/Open System Interfaces Extension.

I have no idea about XSI extensions or if they are being used here, but it did raise my suspicions seeing as it could explain the error I see in Linux that I never get in Windows.

6

Well, Jules. I feel rather stupid. I had installed Ubuntu using the new Windows installer, wubi. What I didn’t realize is that wubi installs 64-bit Linux by default! So, interfacing with a 32 bit system over firewire was actually the source of all the strange behavior I was witnessing - due to the memory corruption when interfacing the 32 bit and 64 bit systems over firewire messaging. Sorry for the wild goose chase. :oops:

7

So - I have this exact error on a stable Linux system with no other problems.

The system had been running under medium heavy load for a few hours, but it's code that is thoroughly burned in.

Could I be exhausting a pthread system? It's a very heavily threaded app - 20+ threads, coming and going.