apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 56063] New: testcond deadlocks on Tru64 V4.0F (PK8)
Date Sat, 25 Jan 2014 16:22:33 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=56063

            Bug ID: 56063
           Summary: testcond deadlocks on Tru64 V4.0F (PK8)
           Product: APR
           Version: 1.5.0
          Hardware: DEC
                OS: OSF/1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR test
          Assignee: bugs@apr.apache.org
          Reporter: urs.traber@gmail.com

Created attachment 31254
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31254&action=edit
same test based directly on pthreads

APR was built with:

-bash-3.2$ CFLAGS='-w2 -c99 -g' ./configure --enable-threads --disable-ipv6
--with-egd=/var/run/egd-pool


Attaching the debugger shows the following:

-bash-3.2$ ladebug -pid 26335 testall
Welcome to the Ladebug Debugger Version 4.0-49
------------------ 
object file name: testall 
Reading symbolic information ...done
Attached to process id 26335  ....


Interrupt (for process)

Stopping process localhost:26335 (testall).
Thread received signal INT
stopped at [<opaque> __nxm_thread_block(...) 0x3ff805b1028]    
(ladebug) show thread  
  Thread Name                      State           Substate    Policy       Pri
  ------ ------------------------- --------------- ----------- ------------ ---
>*    -1 manager thread            blk SCS                     SCHED_RR     19
       1 default thread            blocked         join 122    SCHED_OTHER  19
      -2 null thread for VP 1      running VP 1                null thread  -1
     122 <anonymous>               blocked         mut 108     SCHED_OTHER  19

Information:  An <opaque> type was presented during execution of the previous
command.  For complete type information on this symbol, recompilation of the
program will be necessary.  Consult the compiler man pages for details on
producing full symbol table information using the -g (and -gall for cxx) flags.

(ladebug) where thread 1  
Stack trace for thread 1
#0  0x3ff805b0e1c in __hstTransferRegisters(0x3ffc01b1470, 0x3ff8058d248,
0x3ffc01b1470, 0x3ff80598f04, 0x3ffc01b1470, 0x100000000) in
/usr/shlib/libpthread.so
#1  0x3ff80590514 in __hstTransferContext(0x3ffc01b1470, 0x3ff8058d248,
0x3ffc01b1470, 0x3ff80598f04, 0x3ffc01b1470, 0x100000000) in
/usr/shlib/libpthread.so
#2  0x3ff8058d3d8 in __dspDispatch(0x3ffc01b1470, 0x3ff8058d248, 0x3ffc01b1470,
0x3ff80598f04, 0x3ffc01b1470, 0x100000000) in /usr/shlib/libpthread.so
#3  0x3ff805a4780 in __pthread_join(0x3ffc01b1470, 0x3ff8058d248,
0x3ffc01b1470, 0x3ff80598f04, 0x3ffc01b1470, 0x100000000) in
/usr/shlib/libpthread.so
#4  0x3ffbfff2a88 in apr_thread_join(retval=0x11ffffb50, thd=0x140594e38)
"threadproc/unix/thread.c":217
#5  0x12002bef0 in nested_wait(tc=0x11ffffba0, data=0x11ffffbe0)
"testcond.c":340
#6  0x120008960 in abts_run_test(ts=0x14006e6c0, f=0x12002bcb8,
value=0x11ffffbe0) "abts.c":171
#7  0x12002d0f0 in testcond(suite=0x14006e6c0) "testcond.c":662
#8  0x120009620 in main(argc=2, argv=0x11ffffc48) "abts.c":429
#9  0x120008368 in __start(0x3ffc01b1470, 0x3ff8058d248, 0x3ffc01b1470,
0x3ff80598f04, 0x3ffc01b1470, 0x100000000) in testall

(ladebug) where thread 122  
Stack trace for thread 122
#0  0x3ff805b0e1c in __hstTransferRegisters(0x3ff80597744, 0x3ff8058d248,
0x140103880, 0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so
#1  0x3ff80590514 in __hstTransferContext(0x3ff80597744, 0x3ff8058d248,
0x140103880, 0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so
#2  0x3ff8058d3d8 in __dspDispatch(0x3ff80597744, 0x3ff8058d248, 0x140103880,
0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so
#3  0x3ff8058c780 in __cvWaitPrim(0x3ff80597744, 0x3ff8058d248, 0x140103880,
0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so
#4  0x3ff8058a368 in __pthread_cond_wait(0x3ff80597744, 0x3ff8058d248,
0x140103880, 0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so
#5  0x3ffbffe3334 in apr_thread_cond_wait(cond=0x140594e08, mutex=0x140594dd0)
"locks/unix/thread_cond.c":68
#6  0x12002bac8 in nested_lock_and_wait(box=0x11ffffb58) "testcond.c":275
#7  0x12002afb0 in thread_routine(thd=0x140594e38, data=0x11ffffb58)
"testcond.c":97
#8  0x3ffbfff2804 in dummy_worker(opaque=0x140594e38)
"threadproc/unix/thread.c":142
#9  0x3ff805a5eac in __thdBase(0x3ff80597744, 0x3ff8058d248, 0x140103880,
0x3ff80599200, 0x140103880, 0x0) in /usr/shlib/libpthread.so

(ladebug) show mutex 108  
Mutex  Name                      State Owner  Pri Type     Waiters (+Count)
------ ------------------------- ----- ------ --- -------- --------------------
   108 <anonymous>               Lock     122     Recurs   122
(ladebug) show condition with state == wait  
Cond   Name                      Mutex  Type  Waiters (+Count)
------ ------------------------- ------ ----- ---------------------------------
(ladebug) show condition  
Cond   Name                      Mutex  Type  Waiters (+Count)
------ ------------------------- ------ ----- ---------------------------------
     1 _exc_read_mutex+72(0x3ffc
     2 _exc_read_mutex+112(0x3ff
     3 .bss+72(0x3ffc0512f98)
     4 mq_server_data+72(0x3ffc0
    10 <anonymous>
(ladebug) show condition 10  
Cond   Name                      Mutex  Type  Waiters (+Count)
------ ------------------------- ------ ----- ---------------------------------
    10 <anonymous>
(ladebug) 


>From the stack traces you can see that thread 1 is blocked in "nested_wait"
while joining thread 122. Thread 122 is blocked on mutex 108. Nobody is waiting
for any condition variable.

The reason for this behaviour is the pthread implementation on Tru64 V4.0F and
probably other 4.0x versions. (The test runs fine on V5.1B (PK7) without
recompilation). I've adapted and attached a little C program based on pthreads
only that does pretty much the same as the "nested_wait" test in testcond.c. It
shows the same behaviour on a V4.0F and runs on V5.1B.

Any ideas to disable recursive mutex on Tru64 V4.0x? I found
APR_CHECK_PTHREAD_RECURSIVE_MUTEX.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message