[xml] [Fwd: testThreads hang]




-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
--- Begin Message ---
another fun one -

still on HP-UX 11i, configured with --enable-threads (or perhaps that
was --with-threads). then the make test. the ./testThreads step appears
to hang. a system call trace with tusc shows:

# /usr/contrib/bin/tusc  -l -v 13571
( Attached to process 13571 ("testThreads") [32-bit] )
{115365} _lwp_wait(115372, NULL) ......................... [sleeping]
{115372} ksleep(PTH_MUTEX_OBJECT, 0x40006ff0, 0x40006ff8, NULL) [sleeping]
{115373} In user-mode .................................... [running]
{115374} ksleep(PTH_MUTEX_OBJECT, 0x40006ff0, 0x40006ff8, NULL) [sleeping]
{115375} ksleep(PTH_MUTEX_OBJECT, 0x40006ff0, 0x40006ff8, NULL) [sleeping]
{115376} ksleep(PTH_MUTEX_OBJECT, 0x40006ff0, 0x40006ff8, NULL) [sleeping]
{115377} ksleep(PTH_MUTEX_OBJECT, 0x40006ff0, 0x40006ff8, NULL) [sleeping]
( Detaching from process 13571 ("testThreads") )

it appears that there are five threads waiting on a given mutex. i'm guessing it is held by either 115365 or 115373.

a prospect profile of the process (started manually this time) appears to show that the thread running like a bat out of hell in user space is spending its time in:

45%    45% 8982   89.82  0xc5c3e7b8 xmlRMutexLock
38%    83% 7712   77.12  0xc0038e00 pthread_cond_wait
17%   100% 3480   34.80  0xc5c3e7a8 pthread_cond_wait

the full profile for xmlRMutexLock is:
45% 45% 8982 89.82 0xc5c3e7b8 xmlRMutexLock CODE GLOBAL
 /home/raj/libxml2-2.4.23/.libs/libxml2.sl.6.23
+0x00bc 0xc5c3e874 $PIC_pcrel$40 CODE LOCAL

             356    3.56    +0x0038  : LDW             -100(r30),r1
                            +0x003c  : LDO             100(r1),r26
             389    3.89    +0x0040  : LDW             -100(r30),r25
+0x0044 : BL $PIC_pcrel$40+0x004c,r2 ;
 br dst 0xc5c3e8c0
                            +0x0048  : ADDIL           L%0xfffff800,r2
             355    3.55    +0x004c  : LDO             1768(r1),r1
+0x010c 0xc5c3e8c4 $PIC_pcrel$41 CODE LOCAL

                            +0x0000  : LDSID           (r1),r31
+0x0110 0xc5c3e8c8 $PIC_pcrel$42 CODE LOCAL

             349    3.49    +0x0000  : MTSP            r31,sr0
            2605   26.05    +0x0004  : BLE             0(sr0,r1)
            1558   15.58    +0x0008  : COPY            r31,r2
            2205   22.05    +0x000c  : LDW             -32(r30),r19
                            +0x0010  : LDW             -100(r30),r31
             378    3.78    +0x0014  : LDW             88(r31),r20
787 7.87 +0x0018 : COMIB,<> 0,r20,$PIC_pcrel$40+0x003
8 ; br dst 0xc5c3e8ac

which appears to be a loop - probably calling pthread_cont_wait

/**
 * xmlRMutexLock:
 * @tok:  the reentrant mutex
 *
 * xmlRMutexLock() is used to lock a libxml2 token_r.
 */
void
xmlRMutexLock(xmlRMutexPtr tok ATTRIBUTE_UNUSED)
{
#ifdef HAVE_PTHREAD_H
    pthread_mutex_lock(&tok->lock);
    if (tok->held) {
        if (pthread_equal(tok->tid, pthread_self())) {
            tok->held++;
            pthread_mutex_unlock(&tok->lock);
            return;
        } else {
            tok->waiters++;
            while (tok->held)
                pthread_cond_wait(&tok->cv, &tok->lock);
            tok->waiters--;
        }
    }
    tok->tid = pthread_self();
    tok->held = 1;
    pthread_mutex_unlock(&tok->lock);
#elif defined HAVE_WIN32_THREADS
        EnterCriticalSection (&tok->cs);
        ++tok->count;
#endif
}

sure enough, there is that while look while (tok->held)



--- End Message ---


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]