Wiggins has asked for the wisdom of the Perl Monks concerning the following question:

I have seen a STDERR message roughly(from memory) like:
Thread terminated panic: MUTEX_LOCK (22) (shared.xs line 199) myfilename linenumber
It is on a line that is a 'lock' of a shared hash of shared sub-hashes, with 9000+ entries.

And I am hoping to track down what this means and what would have caused that. I have source for 'shared.xs' (http://cpansearch.perl.org/src/NWCLARK/perl-5.8.8/ext/threads/shared/shared.xs) which I am hoping is the most recent (but am running 5.10 on Fedora).

?What does the (22) signify?
?Line 199 seems to be the end of a structure instance with empty pointers to functions, not actual code. ( MGVTBL sharedsv_shared_vtbl = { )
? is a 'panic' caused by a macro call, or assert or what? What is the coding style Perl source>

It is always better to have seen your target for yourself, rather than depend upon someone else's description.

  • Comment on panic: MUTEX_LOCK (22) - what should I look for?

Replies are listed 'Best First'.
Re: panic: MUTEX_LOCK (22) - what should I look for? (tools)
by tye (Sage) on May 21, 2009 at 18:33 UTC

    Typing "dist://perl" into the PerlMonks Search box (top of this page) takes you to perl. You can select release 10.0 from a drop-down there and Goto that version and then use "Other tools" to grep the source or "browse".

    Line 199 is the first line of: 

    void
recursive_lock_release(pTHX_ recursive_lock_t *lock)
{
    MUTEX_LOCK(&lock->mutex);
    if (lock->owner == aTHX) {
        if (--lock->locks == 0) {
            lock->owner = NULL;
            COND_SIGNAL(&lock->cond);
        }
    }
    MUTEX_UNLOCK(&lock->mutex);
}

    [download]

    from http://cpansearch.perl.org/src/RGARCIA/perl-5.10.0/ext/threads/shared/shared.xs.

    http://cpansearch.perl.org/src/RGARCIA/perl-5.10.0/thread.h contains: 

    #  define MUTEX_LOCK(m) \
    STMT_START {                        \
    int _eC_;                        \
    if ((_eC_ = pthread_mutex_lock((m))))            \
        Perl_croak_nocontext("panic: MUTEX_LOCK (%d) [%s:%d]",    \
                 _eC_, __FILE__, __LINE__);    \
    } STMT_END

    [download]

    So 22 is "eC" (error code, I'd guess). A $! of 22 is "Invalid argument" for a random Linux box I checked. You should be able to grep for pthread_mutex_lock to dig deeper, etc.

    I hope that helps.

    - tye        

[reply]
[d/l]
[select]
[reply]
        I've seen this issue. I certainly don't know all the says this can happen but I saw it this way. I place a lock on a shared variable. It happens to be an array reference. In some operations the locking thread is pushing items onto the array. Others are reading the array and in one case the locking thread is emptying the array. Everything is fine until I attempt the empty the array. I happen to be a huge fan of array references. You will almost never see me use a variable defined as @something or %something. It will nearly always be a scalar holding [] or {}. Old habits die hard so when I want to make the populated array become empty I simple assign [] or in this case &share([]) which is how the exception (fault) is caused. I've not only emptied the object the lock is on I've destroyed it. Once I only emptied and not replaced the array the issue went away so @ $something = (); is the proper way. When it involves sharing and threads.
[reply]

Back to Seekers of Perl Wisdom