PROBLEM: (79254) (PATCH ID: OSF505-0068) ******** In the DECthreads V3.16 codebase, which presently ships with Tru64 UNIX V5.0a, the unused global cell pthread_init_routine was removed, as pthread library initialization now occurs through __init__libpthread(). However, some threaded applications built on Digital UNIX V3.2 era systems still reference the obsolete pthread_init_routine. For compatibility purposes, this patch recreates a pthread_init_routine global cell as a functional NOP allowing applications to resolve the reference in a harmless manner. PROBLEM: (81825) (PATCH ID: OSF505-139) ******** This patch ensures that threads created by programs linked -taso run on stacks with addresses that fit in the 31-bit taso range. Prior to this patch threads created by taso programs were run on stacks with non-taso addresses, which could result in truncated address values, and segmentation faults or data corruption depending on whether the truncated address is valid. PROBLEM: (78701, 79229, 79588, 79745) (PATCH ID: OSF505-204) ******** PROBLEM: (78701) (PATCH ID: ) This patch fixes a memory leak problem for threaded applications that make use of the pthread_attr_setname_np function. PROBLEM: (79229) (PATCH ID: ) This patch fixes a problem when threaded applications use pthread_setname_np. pthread_setname_np would occasionally return an EINVAL error code. PROBLEM: (79588) (PATCH ID: ) The VM subsystem can cause deadlocks on mutexes internal to the threads library. The signature of this problem is a stack trace showing two calls to muGetBlock(). For example, frames 4 and 8 below: >0 0x3ff805c698c in __hstTransferRegisters(0x0, 0x0, 0x3ff8059cedc,... /usr/shlib/libpthread.so #1 0x3ff80597e0c in __hstTransferContext(0x0, 0x0, 0x3ff8059cedc, ... /usr/shlib/libpthread.so #2 0x3ff805927e8 in __dspDispatch(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x... /usr/shlib/libpthread.so #3 0x3ff8059d360 in pthread_mutex_block(0x0, 0x0, 0x3ff8059cedc, 0... /usr/shlib/libpthread.so #4 0x3ff8059ef30 in __muGetBlock(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x0... /usr/shlib/libpthread.so #5 0x3ff8059ced8 in pthread_mutex_block(0x0, 0x0, 0x3ff8059cedc, 0... /usr/shlib/libpthread.so #6 0x3ff805c4214 in UnknownProcedure9FromFile115(0x0, 0x0, 0x3ff80... /usr/shlib/libpthread.so #7 0x3ff805c3454 in __vmFree(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x0, 0x... #8 0x3ff8059f428 in __muGetBlock(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x0... /usr/shlib/libpthread.so #9 0x3ff8058c730 in __cvWaitPrim(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x0... /usr/shlib/libpthread.so #10 0x3ff8058a42c in __pthread_cond_wait(0x0, 0x0, 0x3ff8059cedc, 0... /usr/shlib/libpthread.so #11 0x1200053c4 in mySubroutine(oldtimemusic=0x140005cc0) "myCode.c... #12 0x1200034c4 in myThreadProg(banjo_fiddle=0x140005cc0) "myCode.c... #13 0x3ff805b4350 in __thdBase(0x0, 0x0, 0x3ff8059cedc, 0x0, 0x0, 0... PROBLEM: (79745) (PATCH ID: ) A threaded program may loop in a pthread library internal routine, causing an undue number of PC cycles to be attributed to __krnUnlock. DCPI profiling of such an process might look similar to the following, where __krnUnlock acquires an excessive 76.7% of the CPU time: %time seconds cum % cum sec procedure (file) 76.7 1207.5858 76.7 1207.59 __krnUnlock () 1.8 27.9858 78.5 1235.57 __krnLock () 1.2 19.3380 79.7 1254.91 __dspReadyAny () 1.2 18.9423 80.9 1273.85 proc_at_0x120042740 () 1.1 17.4863 82.0 1291.34 __utlCompareSwapEqPtr () 1.0 16.2385 83.0 1307.58 __utlFetchAndStoreConditional () 0.7 10.4885 84.5 1330.51 proc_at_0x120042f30 () 0.6 9.2181 85.1 1339.72 __utlCompareSwapEqInt () 0.5 7.9820 85.6 1347.71 __dspBlkDequeue () 0.5 7.3117 86.1 1355.02 __hstSetNxmActive () 0.4 6.9619 86.5 1361.98 __krnTryLockThread ()