PROBLEM: (QAR 58658) (Patch ID: OSF425-343) ******** Thread-aware debuggers (particularly TotalView) that make extensive use of the libpthreaddebug.so HOLD/UNHOLD mechanisms for breakpoints may expose a race condition that can lead to a SIGSEGV within the user-mode thread scheduling code. This can lead to a "quiet" process exit: a core file is generated, but no message appears, and the proc filesystem reports a normal termination to the debugger. Other HOLD-related races can result in the process being debugged ignoring the debugger's HOLD request, or in corrupting the saved state of a thread. PROBLEM: (QAR 58658) (Patch ID: OSF425-343) ******** DECthreads can optimize the performance of some common thread operations for programs compiled using DEC C, by utilizing the DEC C asm() syntax to include machine instructions. DECthreads does not use asm() syntax under other compilers, but nevertheless included the DEC C header file . This header is incompatible with the gcc compiler asm() syntax. PROBLEM: (MCPM31P0Q/QAR 60741) (Patch ID: OSF425-407) ******** This patch is a fix to libtli/libxti to correctly handle a continuation data message still on the stream head. PROBLEM: (SSRT0546U, SSRT0542U) (Patch ID: OSF425-405403) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. In addressing this issue, a warning message not previously seen may be placed in the daemon.log by named. An example of the message follows: Jan 7 14:03:25 hostname named[316]: owner name "xx_yy.zz.com" IN (secondary) is invalid - proceeding anyway This message has no impact on system operation and will only be seen once for any given node name on a BIND server at startup. It is informing the user that this node name contains non-standard characters. Standard characters are defined as A-Z, a-z, 0-9 and hyphen. Non-standard characters are characters that fall out of the standard set such as underscores. PROBLEM: (QAR 66683) (Patch ID: OSF425-539) ******** DECthreads was not properly changing the priority of a suspended thread, adversely effecting Java programs. The routine pthread_setschedparam() was not properly handling threads that are suspended. PROBLEM: (QAR 66254) (Patch ID: OSF425-539) ******** The routines, pthread_mutex_trylock() and tis_mutex_trylock(), as coded in the libpthread and libc, respectively, can cause uncontested lock operations to take the "slow path" when they would not have to otherwise. This shows a significant performance problem for the malloc mutex under heavy load. PROBLEM: (QAR 60355) (Patch ID: OSF425-539) ******** A bug in DECthreads affected the preemption of realtime SCS threads. In once instance a low priority SCS thread would run before a higher priority SCS threads. Another problem occurred when one SCS thread joined with another SCS thread, by calling the pthread_join() function before the "target" SCS thread had terminated. In that situation, the joiner thread may never be unblocked from the wait. PROBLEM: (CLD HPAQ81B6C) (Patch ID: OSF425-539) ******** Multithreaded applications can experience performance problems if they are run on multi-cpu systems and make heavy use of any of the functions on the malloc(3) manpage. This includes C++ applications making heavy use of "new" and "delete". The primary fix for this problem exists within libc, however DECthreads contained inefficiencies in the mutex logic code which made the problem worse. PROBLEM: ( QAR 69251) (Patch ID: OSF425-582) ******** With version 52, Ladebug has begun to employ a "user thread hold" mechanism. This patch fixes problems in DECthreads, when using this mechanism, which might result in missed breakpoints and watchpoints, as well as causing application hangs. PROBLEM: ( CLD HPAQ21HQ9) (Patch ID: OSF425-582) ******** This patch fixes a DECthreads problem in which an invalid scheduling priority bugcheck in encountered. This is caused by incorrect referencing of scheduling data structures inside DECthreads. PROBLEM: ( QAR 69364) (Patch ID: OSF425-582) ******** This patch fixes a problem in DECthreads manager thread logic. The manager thread is being scheduled to run in response to a system event (nxm action, timer queue expiration, etc.) but is not recognizing the event as the reason it was scheduled to run. The manager thread then goes back to sleep, only to wake up again in response to the still unserviced system event. An infinite loop results.