PROBLEM: (BRO100738) (Patch ID: OSF415-400080) ******** When testing applications on a BSD-style device such as /dev/tty0h, the ttyslot function returns a number matching the index into the /var/adm/utmp file. However, when running the same program on an SVR4-style device such as /dev/lat/622, the ttyslot function always returns zero. The problem can be indentified easily by running the sample test program included here. Copy the following program to ttyslot_test.c: #include #include #include #include main() { printf("ttyslot() = %d\n", ttyslot()); exit(1); } Error messages may vary, depending on which applications are being run. When connected to a system over an SVR4-style LAT device the application calls the ttyslot function to locate the entry in the /var/adm/utmp file. The ttyslot function returns zero in error because it fails to match the control terminal. When you connect to a system over a LAT device and make a ttyslot function call to locate the entry in the /var/adm/utmp file for the control terminal of the current process, ttyslot() returns zero in error because it fails to match the control terminal. PROBLEM: (QAR 49260) (Patch ID: OSF415-400106) ******** Customer applications that repeatedly call gethostent(), when run on systems configured to use YP and/or bind services for host entries, will see only the entries in the local /etc/hosts file. The problem is not present for similar routines such as gethostbyname(). The only way to reproduce the problem is to write a program that repeatedly calls gethostent() and then verify that it does not return all the entries present in the YP and bind databases served to the machine. PROBLEM: (ULC-43) (Patch ID: OSF415-400119) ******** The customer's application sets a timer to go off every 200 milliseconds via a call to setitimer(). It then loops indefinitely, calling a function that does a setjmp() and then calling a function that does a longjmp(). On Digital UNIX V4.0C r386 (SSB), the application fails with a segmentation fault after a variable number of loop iterations. PROBLEM: (QAR 49787) (Patch ID: OSF415-400133) ******** A multithreaded application that calls any of the system database "get*" functions (gethostent, getservent, etc.) and that calls fork(), may deadlock. DECladebug will show a thread blocking on a mutex lock with the call to fork() on its call stack, while another thread will also be stuck in the mutex blocking function with a function name like gethostbynam() on its stack. Other threads may or may not be stuck on other mutex locks. The two threads in question will never progress. Any subsequent calls to fork will block forever. PROBLEM: (CLD #HPXQ9B161, QAR #48888) (Patch ID: OSF415-400139) ******** On V4.0C and later, when running a call_shared FORTRAN application linked on an earlier release, the loader will issue the error message: "dlopen: Unresolved symbols". The error can also occur in older non-FORTRAN applications that are linked with libc_r.so and call dlopen(). The problem occurs even though there is no explicit reference to the symbol in the application or library. In the particular test reported and fixed by this patch, the DEC FORTRAN Runtime Library (libfor.so) was inadvertently referencing the following libc entry symbols: __index, __rindex, __realtime_kernel, chk_perm, __chk_perm, fchk_perm, __fchk_perm and __list_free. The entry symbols have been replaced in libc. However, in some cases, they are just error termination routines and are treated as unsupported. This fix only handles the resolution of the missing symbols. PROBLEM: (CLD SSRT0425U) (Patch ID: OSF415-400143) ******** 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. PROBLEM: (QAR 50691) (Patch ID: OSF415-400153) ******** A call to popen() was hanging after a call to pclose() with an invalid stream pointer (such as a stream that was not popened) in a threaded program (one built with -pthread). PROBLEM: (50746, 50316) (Patch ID: OSF415-400154) ******** When a call to mallopt(M_MXFAST, value) was performed, the performance of subsequent calls to malloc() slowed by as much as 65 times. PROBLEM: (SSRT0296U) (Patch ID: OSF415-400189) ******** A potential security vulnerability has been discovered in BIND (Domain Name Service), 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. PROBLEM: (QAR #49720) (Patch ID: OSF415-400131) ******** Multithreaded applications running on SMP systems, may find their applications hanging because a thread is never told that a mutex has been unlocked or that a condition variable has been signaled. To recognize this problem, use ladebug to display the list of mutexes and condition variables. (ladebug) pthread "mutex -faq; condition -faq" This will display a very long list of mutexes and condition variables, including those that belong to libc or libpthread. An example of the output follows: (ladebug) pthread "mutex -faq; condition -faq" . . . Mutex 103 (normal) "mutex at 0x140000b10" (0, block 0x140008b90) is orphaned blocking structure, 2 threads waiting; waiters: 56, 51 . . . Condition variable 203, "cond at 0x14030b510" (0) is orphaned blocking structure, 2 threads waiting; waiters: 91, 5 . . . The application will hang forever because the threads are waiting on a blocking structure not attached to the mutex or condition variable. PROBLEM: (QAR #49520) (Patch ID: OSF415-400131) ******** Multithreaded applications running on SMP systems, may find their applications hanging because of a corrupted mutex. To recognize this problem, use ladebug to display the list of mutexes that are locked: (ladebug) pthread "mutex -fal" This will display a list of locked mutexes. Some mutexes will be recursive or error check type mutexes. Those types of mutexes record the thread that owns the lock on the mutex. The corruption is exposed as a recursive or error check mutex without a thread owner: (ladebug) pthread "mutex -fal" Mutex 56 (recursive) "exc cr" (0x3ffc0082f80, block 0x140009d10) is locked (depth 1), 4 threads waiting; ref count is 4 The output should have a "by thread x" after the "is locked" line above. PROBLEM: (QAR #49520) (Patch ID: OSF415-400131) ******** Multithreaded applications may overflow the stacks of created threads prematurely. Applications may receive a SEGV and dump core at unexpected places when this problem occurs. The SEGV should be because a memory location in or near the thread's stack was referenced. To recognize this problem, use ladebug to run appliation in question and wait for the SEGV to occur. Then find the thread that took the SEGV and check to see what value of the stack pointer is. Then display the full information on the thread itself and compare the current stack pointer to the limits displayed. An example debug session: (ladebug) run Thread received signal SEGV stopped at [hstTransferContext: ??? 0x3ff80572ca8] (ladebug) p $sp 0x140028bb8 (ladebug) pthread "thread -f x" thread 2 (running) "" (0x140006030), created by pthread Scheduling: throughput policy at priority 11 Masked signals: none Pending signals: none Terminated, result value 0 Object flags: none; self flags: none; sched flags: none; mutex flags: terminated; atomic flags: none Thread specific data: 0=0x140006488 Stack: 0x14002fa38; base is 0x140030000, guard area at 0x140027fff General cancelability disabled, asynch cancelability disabled Current vp is 0, synch port is 0, vp ID is 0 Join uses mutex 22 and condition variable 7; wait uses mutex 23 and condition variable 8 The thread's start function and argument are 0x120001bc0 (0x3ffc01834c8) The thread's latest errno is 0 You should see that there is a considerable amount of free space on the stack. (0x140028bb8 - 0x140027fff = 0xbb9 or 3001 bytes!) PROBLEM: (QAR #49804) (Patch ID: OSF415-400131) ******** Multithreaded applications which use fork() may find their applications hanging because of a deadlock situation. To recognize this problem, use ladebug to display the list of locked mutexes and their waiters. (ladebug) pthread "mutex -alrq" Mutex 1 (normal) "malloc" is locked by 13848, 4 threads waiting; waiters: 13846, 3, 567, 8 Mutex 10 (normal) "VM 0 cache" is locked, 1 thread waiting; waiters: 1 Mutex 13 (normal) "VM 3 cache" is locked, 1 thread waiting; waiters: 13848 In the example above, the malloc mutex is held by thread 13848, but it is waiting on mutex 13. A stack trace inspection reveals that mutex 13 is held by thread 13846. PROBLEM: (QAR #50961) (Patch ID: OSF415-400195) ******** The native exception handling facility may corrupt the users stack. This is most easily seen in an application using threads since the exception handling facility is always present there. But other applications linked with "-lexc" may see this problem as well. A typical stack trace from Ladebug showing this problem may look like this: (ladebug) t Stack trace for thread 2 >0 0x3ff80579a94 in /usr/shlib/libpthread.so #1 0x3ff80110b98 in /usr/shlib/libc.so #2 0x3ff80110318 in __tis_read_unlock(0x3ff8011031c, 0x3ffc0092500, 0x3ff8017345c, 0x3ffc0092500, 0x3ffc0087fe0, 0x0) DebugInformationStrippedFromFile738 #3 0x3ff80173458 in /usr/shlib/libc.so #4 0x3ff807b2004 in exc_lookup_function_entry(0x14005d180, 0x3ff807b1d30, 0x14005d180, 0x23bd5eb8, 0x3ff807b325c, 0x14005c640) DebugInformationStrippedFromFile0 #5 0x3ff807b3258 in UnknownProcedure16FromFile1(0x0, 0x14005d9a8, 0x100000001, 0x14005c640, 0xabadabad00beed00, 0x3ff80579ac0) DebugInformationStrippedFromFile1 #6 0x3ff807b3634 in exc_unwind(0x100000001, 0x14005c640, 0xabadabad00beed00, 0x3ff80579ac0, 0x3ff807b3b04, 0x3ff807b3aa0) DebugInformationStrippedFromFile1 #7 0x3ff807b3b00 in __Ots_CSpecificHandler(0x3ff807b3980, 0x14005d6f8, 0x14005d6d0, 0x14005d180, 0x3ff00000000, 0x14005d408) DebugInformationStrippedFromFile4 #8 0x3ff807b2ac4 in UnknownProcedure12FromFile1(0x0, 0x3ff8055c8d8, 0x0, 0x63ff0000, 0x14005de78, 0x0) DebugInformationStrippedFromFile1 #9 0x3ff807b2da0 in exc_dispatch_exception(0x14005de78, 0x3ff8055c460, 0x14005d180, 0x23bd5f3c, 0x3ff807b24e0, 0x0) DebugInformationStrippedFromFile1 #10 0x3ff807b2534 in exc_raise_exception(0x3ffc00802a0, 0x0, 0x3ff80579a60, 0x0, 0x3ffc0087650, 0x120002604) DebugInformationStrippedFromFile1 #11 0x14005d17c Note that the last frame (frame #11 above) does not have any information printed. This is symptomatic of the stack being corrupted in such a way that the debugger cannot interpret it correctly. PROBLEM: (QAR 50392) (Patch ID: OSF415-400195) ******** Some applications have bugs in them that developers are trying to find. The nature of these bugs might be to corrupt the internal workings of malloc() or free() such that calling them causes a SEGV. When this happens, it is possible for the native exception handling routines to block while accessing their internal procedure descriptor list, due to some other thread performing a lookup on that list. If the exception handling routines actually try to block, it is possible for the blocking operation itself to try to allocate memory and to call malloc() again. This attempt to call malloc() will hang. A typical stack trace from Ladebug showing this error might look like this: (ladebug) t >0 0x3ff8057ca24 in /usr/shlib/libpthread.so #1 0x3ff8057a450 in hstTransferContext(0x1, 0x140048030, 0x3ffc018a010, 0x4, 0x3ffc0188a50, 0x90) DebugInformationStrippedFromFile109:??? #2 0x3ff8056429c in dspDispatch(0x14000c210, 0x140048c68, 0x140048af0, 0x8f4, 0x3ffc0082770, 0x0) DebugInformationStrippedFromFile89:??? #3 0x3ff80567b98 in pthread_mutex_block(0x3ffc018a1c0, 0x3ffc018a1d0, 0x1400e6ef0, 0x8f4, 0x3ffc0082770, 0x0) DebugInformationStrippedFromFile95:??? #4 0x3ff8057c820 in __pthread_mutex_lock(0x3ffc018a1d0, 0x1400e6ef0, 0x8f4, 0x3ffc0082770, 0x0, 0x3ff80575e88) DebugInformationStrippedFromFile111:??? #5 0x3ff80575e84 in UnknownProcedure3FromFile103(0x8f4, 0x3ffc0082770, 0x0, 0x3ff80575e88, 0x3ff800d194c, 0x0) DebugInformationStrippedFromFile103:??? #6 0x3ff800d1948 in malloc(0x3ff800d194c, 0x0, 0x3ff80579170, 0x90, 0x0, 0x3ffc0184e70) DebugInformationStrippedFromFile22:??? #7 0x3ff8057916c in vmAlloc(0x3ff8055d94c, 0x3ffc0082870, 0x0, 0x0, 0x3ffc018a1c0, 0x3ff8055d934) DebugInformationStrippedFromFile108:??? #8 0x3ff8055d948 in cvGetBlock(0x3ffc0082818, 0x3ffc0082800, 0x14000c040, 0x3ffc008f7ec, 0x3ffc008f868, 0x3ff8057c8fc) DebugInformationStrippedFromFile1:??? #9 0x3ff8055f574 in cvWait(0x3ffc008f868, 0x8f4, 0x3ffc0082870, 0x140048af0, 0x0, 0x3ff80575e88) DebugInformationStrippedFromFile1:??? #10 0x3ff8055d45c in __pthread_cond_wait(0x3ffc0082870, 0x140048af0, 0x0, 0x3ff80575e88, 0x3ff8010fd54, 0x0) DebugInformationStrippedFromFile1:??? #11 0x3ff8010fd50 in /usr/shlib/libc.so #12 0x3ff8010f570 in __tis_write_lock(0x3ff8010f574, 0x3ff8019241c, 0x3ff80172aec, 0x1, 0x3ff800ccda0, 0x1) DebugInformationStrippedFromFile735:??? #13 0x3ff80172ae8 in __exc_lookup_function_entry(0x0, 0x0, 0x3ffc018a010, 0x0, 0x3ff800d1540, 0x1401e5020) DebugInformationStrippedFromFile304:??? #14 0x3ff807b2004 in exc_lookup_function_entry(0x3ffc018a010, 0x0, 0x3ff800d1540, 0x1401e5020, 0x3ff807b2bec, 0x1400249e0) DebugInformationStrippedFromFile0:??? #15 0x3ff807b2be8 in exc_dispatch_exception(0x0, 0x12009407c, 0x140122910, 0x140020000, 0x0, 0x0) DebugInformationStrippedFromFile1:??? #16 0x3ff807b38c4 in exc_raise_signal_exception(0x80, 0x0, 0x3ff8019241c, 0x1, 0x1, 0x140048af0) DebugInformationStrippedFromFile3:??? #17 0x3ff800d3b28 in __sigtramp(0x3ff8019241c, 0x1, 0x1, 0x140048af0, 0x140122ef8, 0x0) DebugInformationStrippedFromFile105:??? #18 0x3ff8019241c in UnknownProcedure22FromFile22(0x3ffc0080c50, 0x1, 0x14017cc00, 0x2f, 0x140024f20, 0x3ff8057c824) DebugInformationStrippedFromFile22:??? #19 0x3ff80192f40 in UnknownProcedure17FromFile22(0x3ff801943c8, 0x1, 0x10, 0x3ffc0080e18, 0x72, 0x140024f20) DebugInformationStrippedFromFile22:??? #20 0x3ff801943c4 in /usr/shlib/libc.so #21 0x3ff80194604 in /usr/shlib/libc.so #22 0x3ff800d1958 in malloc(0x3ff800d195c, 0x0, 0x12008e3bc, 0x140024f20, 0x1401232a0, 0x14017cc00) DebugInformationStrippedFromFile22:??? #23 0x12008e3b8 in lxldalc() /vobs/nlsrtl3/src/lxi/lxldalc.c:54 Note that frame #23 has a call to malloc(). In frame #16 a synchronous signal (such as a SEGV) is taken, which results in an exception being raised. Notice in frame #6 that malloc() is called again as part of handling the exception, which leads to the thread blocking. This is because the previous call to malloc() caused it to lock its internal mutex for synchronization purposes. This recursive call to malloc() is the problem. The user might be able to fix the cause of the original SEGV if its accompanying exception is fully processed. This patch allows the SEGV to be processed fully and correctly. PROBLEM: (QAR 49804) (Patch ID: OSF415-400195) ******** Threaded applications may see hangs when trying to use fork(). A prior patch fixed only a part of the problem. The user sees the child process with a stack trace from Ladebug like this: (ladebug) t >0 0x3ff8057ca24 in /usr/shlib/libpthread.so #1 0x3ff8057a450 in hstTransferContext(0x1, 0x140ae11f0, 0x3ffc018a010, 0x4, 0x3ffc0188a50, 0x3ffc01852c0) DebugInformationStrippedFromFile109:??? #2 0x3ff8056429c in dspDispatch(0x140051810, 0x1408641a8, 0x140864030, 0x0, 0x3ffc01851d0, 0x0) DebugInformationStrippedFromFile89:??? #3 0x3ff80567b98 in pthread_mutex_block(0x3ffc008ae28, 0x3ffc01876f8, 0x140621c00, 0x0, 0x3ffc01851d0, 0x0) DebugInformationStrippedFromFile95:??? #4 0x3ff8057c820 in __pthread_mutex_lock(0x3ffc01876f8, 0x140621c00, 0x0, 0x3ffc01851d0, 0x0, 0x3ff8057984c) DebugInformationStrippedFromFile111:??? #5 0x3ff80579848 in vmReinit(0x0, 0x3ff8057984c, 0x3ff80578e70, 0x0, 0x3ffc0080c50, 0x3ffc0081de0) DebugInformationStrippedFromFile108:??? #6 0x3ff80578e6c in /usr/shlib/libpthread.so #7 0x3ff800d36e0 in __fork(0x120040830, 0x0, 0x140684bc0, 0x0, 0x1f, 0x0) DebugInformationStrippedFromFile335:??? #8 0x12004082c in forkTranslator(inoutp_handle=0x140a9b8f8, inoutp_operation_data=0x140763a00) dp_xlatr.c:3610 #9 0x12004040c in forkedTranslatorInterface(inoutp_handle=0x140a9b8f8, in_operation_code=eConnect, inoutp_operation_data=0 x140763a00, getr=0x0, putr=0x0, arg_p=0x0) dp_xlatr.c:3471 #10 0x12003e0c0 in dp_callTranslator(inoutp_handle=0x140a9b8f8, in_operation_code=eConnect, inoutp_operation_data=0x140763a00, inp_scb=0x140621c00, getr=0x0, putr=0x0, arg_p=0x0) dp_xlatr.c:1894 #11 0x12003d878 in dp_connectToTranslator(inp_scb=0x140621c00) dp_xlatr.c:1468 #12 0x1200649d0 in dp_pjaConnectToTranslator(inp_Scb=0x140621c00, in_docPdlOid=1252, inoutp_printerPdlOid=0x140a9b988, outp_needsTranslator=0x140a9b9a8) pja_doc.c:726 #13 0x12005b4a0 in startDocument_1(getr=0x12004bb0c, putr=0x12005dc40, inp_fib=0x140a53c00) dp_pja.c:1508 #14 0x12004b234 in fiberRoutineJacket(inp_fib=0x140a53c00) dp_jbstp.c:1276 #15 0x12004b430 in fibThreadJacket(inp_fib=0x140a53c00) dp_jbstp.c:1331 #16 0x3ff80574b94 in thdBase(0x0, 0x3ffc0183430, 0x3ffc018a010, 0x1, 0x45586732, 0x3) DebugInformationStrippedFromFile101:??? Note that frame #7 above shows the call to fork(). The DECthreads library is then entered with an attempt to lock a DECthreads internal mutex in frame #4. This attempt causes the thread to block while waiting for another thread to unlock the mutex. But because this is the only thread left in the child process after the parent forks, this mutex will never be unlocked. The parent failed to lock this mutex during the fork operation and so is incorrectly left in the locked state in the child. PROBLEM: (HPXQ10P01, HPXQB7HGW) (Patch ID: OSF415-400195) ******** For a threaded application written on a system prior to Digital UNIX V4.0C that uses C and the DECthreads exception handling macros, or a threaded application written with C++ on any version of Digital UNIX that also uses the DECthreads exception handling macros, various synchronous signals might not be caught by the application's exception handlers. The DECthreads library is not properly raising synchronous signals as exceptions that the application can catch. PROBLEM: (QAR 51033) (Patch ID: OSF415-400195) ******** Threaded applications using pthread_kill() may experience a stack corruption. This is rather difficult to detect. PROBLEM: (QAR 51214) (Patch ID: OSF415-400195) ******** A threaded application can experience a DECthreads bug check with a message that mentions the routine nxm_resched(). This application might also hang with one of its threads having a stack trace containing a frame for a call to the routine errBugcheck(). The formatted DECthreads bugcheck message might look like this: DECthreads bugcheck (version V3.13-435), terminating execution. vpUpcallThreadUnblocked: (os/kern) invalid argument (4) nxm_resched(20,0) For a hung application in this scenario, a typical stack trace from Ladebug might look like this: (ladebug) t >0 0x3ff80568b20 in pthread_mutex_unblock(0x3ffc00802a0, 0x0, 0x0, 0x3ffc0181580, 0x3ffc018a968, 0x0) DebugInformationStrippedFromFile95:??? #1 0x3ff8057c1f8 in __pthread_mutex_unlock(0x0, 0x0, 0x3ffc0181580, 0x3ffc018a968, 0x0, 0x3ff80575618) DebugInformationStrippedFromFile111:??? #2 0x3ff80575614 in UnknownProcedure5FromFile103(0x3ffc0181580, 0x3ffc018a968, 0x0, 0x3ff80575618, 0x3ff800d6904, 0x3ffc0187760) DebugInformationStrippedFromFile103:??? #3 0x3ff800d6900 in fflush(0x3ff800d6904, 0x3ffc0187760, 0x3ff80565cfc, 0x3ffc018a968, 0x3ffc0187768, 0x0) DebugInformationStrippedFromFile84:??? #4 0x3ff80565cf8 in errBugcheck(0x3ffc0185da0, 0x3ffc01700d8, 0x4, 0x26e, 0x0, 0x3ffc018aae0) DebugInformationStrippedFromFile90:??? #5 0x3ff8057bcd4 in UnknownProcedure26FromFile109(0x0, 0x14014b438, 0x3ffc018a968, 0x3ffc018a968, 0x1, 0x14014b438) DebugInformationStrippedFromFile109:??? #6 0x3ff8057b0d8 in UnknownProcedure20FromFile109(0x500, 0x1f4, 0x1, 0xffffffffdfbbee16, 0x1f4, 0x14014b478) DebugInformationStrippedFromFile109:??? #7 0x3ff80535200 in msg_receive(0x0, 0x3ffc018abf0, 0x0, 0x0, 0x3ffc018a968, 0x0) DebugInformationStrippedFromFile6:??? #8 0x3fefffffffd in ??? Note that frame #8 above is not readable. This is to be expected because the problem is occuring in an "upcall" frame. (This "upcall" frame is used by the kernel to call into user space to perform an operation). Note that frame #4 above contains the DECthreads bugcheck call, but also note that it eventually calls pthread_mutex_unblock() (frame #0 above). This call to pthread_mutex_unblock() hangs because it is incorrect to call pthread_mutex_unblock() within the context of an upcall. PROBLEM: (QAR 51214) (Patch ID: OSF415-400210) ******** A threaded application might hang while attempting to issue a message from the DECthreads bugcheck. A stack trace of a thread in this state will contain frames for calls to the routines errBugcheck(), fflush() and pthread_mutex_ unblock(). (ladebug) t >0 0x3ff80568b20 in pthread_mutex_unblock(0x3ffc00802a0, 0x0, 0x0, 0x3ffc0181580, 0x3ffc018a968, 0x0) DebugInformationStrippedFromFile95:??? #1 0x3ff8057c1f8 in __pthread_mutex_unlock(0x0, 0x0, 0x3ffc0181580, 0x3ffc018a968, 0x0, 0x3ff80575618) DebugInformationStrippedFromFile111:??? #2 0x3ff80575614 in UnknownProcedure5FromFile103(0x3ffc0181580, 0x3ffc018a968, 0x0, 0x3ff80575618, 0x3ff800d6904, 0x3ffc0187760) DebugInformationStrippedFromFile103:??? #3 0x3ff800d6900 in fflush(0x3ff800d6904, 0x3ffc0187760, 0x3ff80565cfc, 0x3ffc018a968, 0x3ffc0187768, 0x0) DebugInformationStrippedFromFile84:??? #4 0x3ff80565cf8 in errBugcheck(0x3ffc0185da0, 0x3ffc01700d8, 0x4, 0x26e, 0x0, 0x3ffc018aae0) DebugInformationStrippedFromFile90:??? #5 0x3ff8057bcd4 in UnknownProcedure26FromFile109(0x0, 0x14014b438, 0x3ffc018a968, 0x3ffc018a968, 0x1, 0x14014b438) DebugInformationStrippedFromFile109:??? #6 0x3ff8057b0d8 in UnknownProcedure20FromFile109(0x500, 0x1f4, 0x1, 0xffffffffdfbbee16, 0x1f4, 0x14014b478) DebugInformationStrippedFromFile109:??? #7 0x3ff80535200 in msg_receive(0x0, 0x3ffc018abf0, 0x0, 0x0, 0x3ffc018a968, 0x0) DebugInformationStrippedFromFile6:??? #8 0x3fefffffffd in ??? Note that frame #8 above is not readable. This is to be expected because the problem is occuring in an "upcall" frame. (This "upcall" frame is used by kernel to call into user space to perform an operation). Note that frame #4 above contains the DECthreads bugcheck call, but also note that it eventually calls pthread_mutex_unblock() (frame #0 above). This call to pthread_mutex_ unblock() hangs because it is incorrect to call pthread_mutex_unblock() within the context of an upcall. PROBLEM: (EVMS-GRYPHON-FT QAR 00237) (Patch ID: OSF415-400210) ******** This patch fixes a situation where threads would hang in the pthread_once() or cma_once() routines. The DECthreads routines pthread_once() and cma_once() use the DECthreads global mutex. The first thread to call pthread_once() or cma_once() would lock this mutex and subsequent threads calling pthread_once() or cma_once() would hang. This problem was fixed on OpenVMS and the patch has been ported to Digital UNIX 4.0. PROBLEM: (IPMT HPAQ11MMTG) (Patch ID: OSF415-400210) ******** For the signals traditionally representing synchronous errors in a program (such as SIGPIPE, SIGSYS, SIGSEGV, SIGBUS, SIGFPE, SIGEMT, SIGIOT, SIGILL), DECthreads catches the signal and converts it into an equivalent exception. Digital UNIX 4.0 attempts to print an abort message for an unhandled exception. If an unhandled exception occurs in a libc library I/O routine, the thread causing the exception may hang in abort() because of a deadlock over an I/O mutex. PROBLEM: (QAR 52332, 51161) (Patch ID: OSF415-400226) ******** This patch corrects problems encountered when using signals with multithreaded programs. It is possible for threaded applications to lose signals on occasion. PROBLEM: (QAR 52339) (Patch ID: OSF415-400226) ******** This patch corrects a random memory corruptor in multithreaded applications. PROBLEM: (IPMT HPAQ309UJ) (Patch ID: OSF415-400226) ******** This patch corrects problems encountered where multithreaded applications fail to create threads with user allocated stacks. PROBLEM: ( HPAQB17NM, QARs 50343,49427,52143 ) (Patch ID: OSF415-400227) ******** When the /etc/passwd files are very large, a performance degradation may occur. When the number of passwd entries reaches up into the 30,000 to 80,000 range, mkpasswd will sometimes fail to create an ndbm database. Since the purpose of this database is to allow for efficient (fast) searches for passwd file information, failure to build it causes a serious performance degradation for commands that rely on it. PROBLEM: (QAR 45580) (Patch ID: OSF415-400239) ******** Multithreaded applications that call the pthread_mutex_destroy routine may fail when there are no threads referencing the mutex. This is caused by a race condition inside the pthread_mutex_unlock code. The typical symptom will be a return value of EBUSY from pthread_mutex_destroy. *** NOTE *** Applications using "inline" mutex operations, as described in the pthread.h header file, will need to RECOMPILE with the application of this patch. The instruction sequences for the pthread_mutex_unlock routine have changed. Please refer to the existing note in pthread.h entitled "NOTICE: inline function performance vs. binary compatibility" for more information. PROBLEM: (QAR 52332) (Patch ID: OSF415-400239) ******** Over time, a multithreaded application may find that asynchronous signals are not being delivered to it. The asynchronous signal may have originated outside the application or from within it. The effect will be that the signal is pending against a thread, the thread will NOT have the signal blocked, but it will not be delivered to that thread. PROBLEM: (QAR 00237) (Patch ID: OSF415-400241) ******** This patch fixes a situation where threads would hang in the DECthreads POSIX 1003.41/Draft 4 (d4) interface's pthread_once() routine. The d4 legacy routine pthread_once() uses the DECthreads global mutex. The first thread to call pthread_once() would lock this mutex and subsequent threads calling pthread_once() would hang. This problem was fixed on OpenVMS and the patch has been ported to Digital UNIX 4.0. PROBLEM: (QAR 52405, QAR 52710) (Patch ID: OSF415-400261) ******** The problem this patch fixes shows up only in multithreaded applications. File descriptors opened by the application may unexpectedly be closed when NIS or RPC services are called, either directly or through remote database lookups (e.g., getpwent()). Subsequent I/O operations on the applications file descriptor will typically produce an error with errno set to EBADF. PROBLEM: (QAR 52450, QAR 52464) (Patch ID: OSF415-400261) ******** The problem this patch fixes will only show up in multithreaded applications. The problem symptoms are that heavy usage of any of the several database lookup functions such as getpwent() and getprotoent(), from multiple short-lived threads, may eventually result in the application getting a segmentation violation, core dumping, and exiting. PROBLEM: (CLD HPAQ30CW2, QAR 51943) (Patch ID: OSF415-400302) ******** This patch fixes a problem in which the rcmd function may cause the system to dump core. User applications that produce a call to rcmd() may experience this problem. Typically, the application has calls to either the fget() or fclose() function. PROBLEM: (QAR 53701) (Patch ID: OSF415-400307) ******** In applications linked with -pthreads, the process signal mask is being lost (set to zero) in the child process following a fork() operation. PROBLEM: (QAR 53767) (Patch ID: OSF415-400307) ******** Occasionally, under certain load condtions, a DECthreads bugcheck occurs in pthread_kill(). This results in a core dump. PROBLEM: (Patch ID: OSF415-400331) ******** When the /etc/passwd file is very large, a performance degradation may occur. When the number of passwd entries reaches up into the 30,000 to 80,000 range or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database. Since the purpose of this database is to allow for efficient (fast) searches for passwd file information, failure to build it causes commands that rely on it to do a linear search of /etc/passwd. This results in a serious performance degradation for those commands. For customers choosing to use the mkpasswd -s option to avoid this type of failure, a potential database/binary compatibility problem may arise. If a customer application that accesses the password database created by mkpasswd is built statically (non-shared), that application will be unable to read from or write to the password database correctly. This would cause the customer application to fail either by generating incorrect results or by possibly dumping core. Any statically linked application would be affected if it directly or indirectly calls any of the libc ndbm routines documented in the ndbm(3) man page and then accesses the password database. To remedy this situation, the customer would need to re-link the application. Customers who do not use the mkpasswd -s option will not see this database/ binary compatibility problem. PROBLEM: (QAR 53135, QAR 44398) (Patch ID: OSF415-400323) ******** This patch fixes a TCP/IP problem that can occur with programs linked with the libc library. These programs may return a value of (-1) when calling the svc_tcp() function. This problem occurs because a return value, EINTR, is ignored in the readtcp() and writetcp() functions. The patch involved checking for this return before continuing a readtcp() and writetcp(). PROBLEM: (QAR 53589) (Patch ID: OSF415-400334) ******** In applications linked with -pthreads, the parent and child processes of a fork() operation may be seen to hang if an exception occurs during the fork() processing. PROBLEM: (Patch ID: OSF415-400348) ******** The mkpasswd command dumps core when user just types 'mkpasswd -s' with no other arguments. It also wasn't using the page block size of an existing database if the -s option was not specified. PROBLEM: (QAR 55232) (Patch ID: OSF415-400372) ******** Broadcasts of a condition variable was occassionally being lost, even though there were threads actually waiting on that condition variable. The result was that threads would never receive notice to unblock and start running again. This problem is most evident on multiprocessor systems. PROBLEM: (QAR 55647) (Patch ID: OSF415-400372) ******** During the search for exception handlers, DECthreads unwound the stack and, in the process, removed the stack frame in which the exception occured. The result was an incorrect stack trace with missing frames. PROBLEM: (QAR 55153) (Patch ID: OSF415-400400) ******** There is a problem in the statically initialized mutex operations. If the preprocessor symbol _PTHREAD_NOMETER_STATIC is not defined, a statically initialized mutex makes a call into DECthreads before it attempts to lock or to unlock for the first time. This call provides metering information. If the metering is not enabled, the mutex, in its subsequent attempts to unlock, will not make the call into DECthreads unless there is contention. There was a bug in the call which is causing the mutex to make the call every time it attempt to lock or to unlock. The bug results into slow mutex operations. The dynamically initialized mutex operations are unaffected by the bug. The fix helps all statically initialized mutex operations that do not use metering. PROBLEM: (Patch ID: OSF415-400402) ******** A call to the libc dbm_open() routine followed immediately by a call to dbm_close() causes hashed database directory files to be truncated and applications that do such a thing to fail. PROBLEM: (CLD HPAQA0X6X) (Patch ID: OSF415-400403) ******** There is a bug in the DECthreads libpthread library for Digital UNIX 4.0 and later that is manifested by calling pthread_cond_timedwait() with an unusually large timeout value (greater than 23 days). The symptom is that the threaded program takes up a significant amount of CPU time (close to 100%). The bug does not occur if the timeout value is either less than 2,000,000 seconds or more than 5,000,000 seconds. With the fix, pthread_cond_timedwait() can be called with any timeout value. PROBLEM: (QAR 48541) (Patch ID: OSF415-400410) ******** Executables that are explicitly linked call_shared with the archive version of libc (libc.a) and *not* the shared library version of libc (libc.so) may have problems using libc features that are supported by the loader. These loader features are documented in the loader(5) man page in the section that describes the low level _rld_new_interface() routine and includes running the application's fini routines (if any) and proper functioning of the dl* routines such as dlopen(3). One might be able to identify this problem by using the debugger to set a breakpoint in the _rld_new_interface() routine and running the application with the failing loader feature(s). If the breakpoint is hit and the _rld_new_interface() is simply doing a return, the libc archive version of _rld_new_interface() which is defined in ldr_dummy.o is being run instead of being preempted by a call into the loader. Relinking the application with the patched version of libc.a should correct this problem. PROBLEM: (QAR 56298) (Patch ID: OSF415-400408) ******** There is a problem in the Bind (Domain Name Service) patch which may cause incorrect messages to be reported from certain networking related applications and from certain networking related functions in the C runtime library. It may also cause segmentation violations in existing statically linked applications using the US english message catalog, and in dynamically linked applications using non-english message catalogs. In all cases the problem will only occur if the LANG environment variable is set. PROBLEM: (GOZ100846) (Patch ID: OSF415-400417) ******** If the server to which an auditd daemon has been configured to send its audit information becomes unavailable, the local auditd daemon cpu usage rises dramatically. PROBLEM: (QAR 52255,QAR 52836,QAR 55617) (Patch ID: OSF415-400430) ******** This patch fixes a problem in which RPC client functions do not correctly handle system calls interrupted by a signal (EINTR errors). If a multi-threaded RPC client process catches a signal, a read or write to an an RPC socket can get interrupted, and the RPC operation fails. PROBLEM: (QAR 56286) (Patch ID: OSF415-400448) ******** There is a problem with the readdir function in that the readdir_r() function reads past the end of its input buffer. The readdir_r() function is using memcpy to copy data that's partly off the end of its internal buffer. This happens when the buffer is close to an unmapped page. PROBLEM: (Patch ID: OSF415-405168) ******** There is a bug in last-chance exception handler. The last-chance exception handler removes all signal handlers prior to terminating the process. The last-chance handler also provides a mechanism of terminating the main thread via pthread_exit or pthread_cancel. The signal handlers are erroneously removed when the main thread exits. This patch corrects the problem and does remove signal handlers until the termination of the process. PROBLEM: (QAR 57320) (Patch ID: OSF415-405169) ******** This patch fixes a bug found in the 'pthread_kill' routine. The bug may cause a multithreaded application to terminate when the application sends a kill signal to a terminated thread. When a thread is terminated, a kill signal sent to such a thread is suppose to return with ESRCH error status. A bug causes `pthread_kill` to terminate the application. With the fix, the caller of 'pthread_kill' receives ESRCH value if the thread is terminated. PROBLEM: (QAR 59249) (Patch ID: OSF415-405192) ******** If a program attempts to create a thread with stacksize or guardsize greater than max signed long integer and if pthread_create can not allocate the requested stacksize or guardsize then it should return ENOMEM without creating a thread. There is a bug in libpthread that causes pthread_create to create a thread without allocating the requested stacksize or guardsize. This patch fixes the bug. With the fix, pthread_create returns ENOMEM without creating the thread if it cannot allocate the requested stacksizeor guardsize. PROBLEM: (HGOQ10179, QAR 58378) (Patch ID: OSF415-405179) ******** This patch fixes a problem with the syslog function. Some syslog messages fail to get written to a log file when the system is experiencing a heavy I/O load. PROBLEM: (MGO103361/QAR 58563) (Patch ID: OSF415-405181) ******** This patch fixes a problem with rexec(3) losing socket descriptors. Applications that call rexec(3) may not work correctly. PROBLEM: (QAR 47388, QAR 51864, QAR 52427, QAR 58881) (Patch ID: OSF415-405191) ******** This patch fixes a problem with the statvfs function. statvfs returns a wrong status when the file system is full. PROBLEM: (QAR 59440) (Patch ID: OSF415-405217) ******** If a program linked with libpthread or libpthreads calls realloc with a NULL pointer and a zero new size (realloc(0,0)), the program will hang on the next call to malloc, free, realloc, calloc or valloc. PROBLEM: (QAR 59959 CLD TKTB36537) (Patch ID: OSF415-405217) ******** Calls to valloc() with a requested size of < 640 bytes will result in the memory being lost when free is called for that chunk. The free routine does not recognize the memory as belonging to the malloc allocator suite. PROBLEM: (QAR 30442, QAR 53287, QAR 57097, CLD UVO105627) (Patch ID: OSF415-405175) ******** This patch fixes exceptions propagating out of __init routines which results in infinite loops. The problem is caused by the routine exc_dispatch_exception() within libexc.a not knowing when to stop searching the stack for a handler. When an C++ exception is issued from an __init function, it is not caught by the last chance handler. Instead, the following message is displayed: exception system: exiting dues to multiple internal errors: exception dispatch or unwind stuck in infinite loop PROBLEM: (HPAQ17931, HPAQA353A) (Patch ID: OSF415-400115) ******** On systems running enhanced security, if a customer's application calls the auth_for_terminal() routine when the v_users keyword has been specified for a device in the device assignment database (/etc/auth/system/devassign) specifying the users that are permitted to login on that device, and a user who is not on the v_users list attempts to login on that device, the customer's application will fail with a segmentation fault. PROBLEM: (CLD HGOQB0282) (Patch ID: OSF415-400203) ******** On a system using enhanced security, login attempts at a graphics console can fail, giving the message "Terminal is disabled -- see Account Administrator." This failure persists even after using dxaccounts or edauth to clear the t_failures entry for the display in the terminal control database. PROBLEM: (QAR51557) (Patch ID: OSF415-405165) ******** A potential audit vulnerability has been discovered, where under certain circumstances, the audit trail of a user may be compromised. Digital has corrected this potential vulnerability. PROBLEM: (QAR 58740) (Patch ID: OSF415-410156) ******** This patch fixes an AdvFS response time problem that occurred when an application with many random access reads of many files was being slowed down by the resulting number of writes to disk. To fix the problem, there are three new features: o atimes and noatimes options are added to the mount -o option list for AdvFS file systems o the read system call has additional code to perform the operation requested by the noatimes option o a configurable parameter, AdvfsPreallocAccess, for tuning the number of access structures in the freelist at startup The AdvFS mount option noatimes changes AdvFS behavior for regular files in the specified fileset. AdvFS updates the file access time in memory on a read system call from a regular file, but does not write the stat structure for the file with the new access time out to disk until some other file modification is made. PROBLEM: (QAR 61080) (Patch ID: OSF415-405272) ******** In threaded applications, user-installed handlers for synchronous signals may be ignored during a fork() operation. Receipt of a synchronous signal at that time would cause the system default action to be taken. PROBLEM: (CLD MGO103500) (Patch ID: OSF415-405308) ******** When swscanf() processes a scanset, the function does not treat the last character of a specified range as part of the scanset. For example, if "[C-U]" is the scanset, swscanf() does not include "U" in the set of characters to be read and converted. When this patch is installed, the last character in a scanset's range of characters is correctly included in processing. PROBLEM: (QAR 54708, CLD MCSM71N73) (Patch ID: OSF415-405312) ******** The printing of a string with a specified precision could result in a segmentation fault. In this case, the C Standard does NOT require a NULL terminated input. PROBLEM: (QAR 52972,QAR 56187,QAR 46392, QAR 44097,QAR 41614) (Patch ID: OSF415-405317) ******** This patch fixes a problem with disklabel, where disks cannot be labeled if they do not support the DEVGETGEOM ioctl or if they do not provide disk geometry information. Typically, IDE devices will cause this problem. The fix allows drives which do not support the DEVGETGEOM ioctl, or drivers which do not provide any geometry information, to provide their geometry information in the /etc/disktab file. PROBLEM: (QAR 54514) (Patch ID: OSF415-405321) ******** A call to dbm_open() followed immediately by a call to dbm_close() caused hashed database directory files to be unnecessarily flushed. PROBLEM: (QAR 60130, QAR 52438) (Patch ID: OSF415-405321) ******** The ndbm routines were not threadsafe because of problems with the definition and use of the buffer ovfbuf and dbm_open had some problems in its error handling code. The calculation of the page block size in dbm_open() had a potential problem because it did not check whether a key datum exceeded a size limit. PROBLEM: (CLD HPAQ51QQZ) (Patch ID: OSF415-405341) ******** This patch fixes a problem in the audit daemon when it is used as a network server. Child auditd processes that are serving network connections fail to reap their child processes (such as when log files are compressed), leaving them as defunct processes on the system. PROBLEM: (MCGM11S2W) (Patch ID: OSF415-405349) ******** This patch resolves a problem with Enhanced Security not handling a voucher correctly from some other security mechanism such as DCE. The scenario to reproduce the problem would be: a user incorrectly enters his username at the first "login:" prompt, but subsequently corrects the login name when prompted again after the first failure. Without this patch, the user upon successfully typing their login/password on the second try would still receive the message "login incorrect". PROBLEM: (CLD BRO101218 / QAR 61257) (Patch ID: OSF415-405380) ******** This patch fixes the printing of floating point values when both the precision and width are specified. This problem can be reproduced as follows: - Create the following program test.c: #include main() { double toto; toto=5555555.; printf("%+046.15E \n",toto); printf("%+046.16E \n",toto); printf("%+046.17E \n",toto); printf("%+046.18E \n",toto); printf("%+046.19E \n",toto); } - cc test.c - a.out Incorrect Results: +0000000000000000000000005.555555000000000E+06 +000000000000000000000005.5555550000000000E+06 +000000000000000000000005.55555500000000000E+06 +000000000000000000000005.555555000000000000E+06 +000000000000000000000005.5555550000000000000E+06 Correct Results: +0000000000000000000000005.555555000000000E+06 +000000000000000000000005.5555550000000000E+06 +00000000000000000000005.55555500000000000E+06 +0000000000000000000005.555555000000000000E+06 +000000000000000000005.5555550000000000000E+06 PROBLEM: (CLD SOO101148, QAR 60948) (Patch ID: OSF415-405381) ******** This patch fixes a memory leak in the libc glob() function. PROBLEM: (QAR 62714) (Patch ID: OSF415-405391) ******** This patch fixes a virtual memory problem that may cause the system to panic with one of the following messages. pmap_begin_mutex_region timeout or: simple_lock timeout PROBLEM: (SSRT0546U, SSRT0542U) (Patch ID: OSF415-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: (CLD's BCGMC1GJ4, HPAQC1L0D, HPAQC1L10) (Patch ID: OSF415-405520) ******** This patch fixes a problem in which BIND client applications are not able to resolve node names. Network applications running on a BIND client such as ping, telnet, and ftp using node names that are resolved by a BIND server will result in resolution errors such as "unknown host". In addressing security releated BIND issues, an area BIND functionality was altered. Non-standard characters that fall out of the standard set such as underscores caused a node name resolution problem. In addition, when "bind" is the first service listed for the "hosts" database in /etc/svc.conf, BIND lookups would fail. PROBLEM: (QAR 59367) (Patch ID: OSF415-410172) ******** This patch adds automatic detection of a cdfs file system for the mount(8) command. PROBLEM: (QAR 56531 QAR 56516 QAR 56530 QAR 56529) (Patch ID: OSF415-400437) ******** Commands vquota, vedquota, quota, edquota, dump, csh, and nslookup will sometimes display the incorrect error message for non-english locales.