Note: This is a MANDATORY Patch. PROBLEM: (BRO100738) (Patch ID: OSF410-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: OSF410-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: OSF410-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.0 r386 (SSB), the application fails with a segmentation fault after a variable number of loop iterations. PROBLEM: (QAR 49787) (Patch ID: OSF410-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: (HPXQ9B161, QAR 48888) (Patch ID: OSF410-400139) ******** On V4.0 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: (SSRT0425U) (Patch ID: OSF410-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: OSF410-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: (QAR 50746, 50316) (Patch ID: OSF410-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: OSF410-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: (HPAQB17NM, QAR 50343, 49427, 52143) (Patch ID: OSF410-400227-1) ******** When the /etc/passwd files are very large, a performance degradation may occur. When the number of passwd entries reaches up into the 30,000to 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 49720) (Patch ID: OSF410-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: OSF410-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 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: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-400195) ******** For a threaded application written on a system prior to DIGITAL UNIX V4.0 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: OSF410-400195) ******** Threaded applications using pthread_kill() may experience a stack corruption. This is rather difficult to detect. PROBLEM: (QAR 51214) (Patch ID: OSF410-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 ??? 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: OSF410-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: OSF410-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: (HPAQ11MMTG) (Patch ID: OSF410-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: OSF410-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: OSF410-400226) ******** This patch corrects a random memory corruptor in multithreaded applications. PROBLEM: (HPAQ309UJ) (Patch ID: OSF410-400226) ******** This patch corrects problems encountered where multithreaded applications fail to create threads with user allocated stacks. PROBLEM: (QAR 00237) (Patch ID: OSF410-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 45580) (Patch ID: OSF410-400239-1) ******** 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 "NOTICED: inline function performance vs. binary compatibility" for more information. PROBLEM: (QAR 52332) (Patch ID: OSF410-400239-1) ******** 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 52405, 52710) (Patch ID: OSF410-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, 52464) (Patch ID: OSF410-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: (HPAQ30CW2, QAR 51943) (Patch ID: OSF410-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: OSF410-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: OSF410-400307) ******** Occasionally, under certain load condtions, a DECthreads bugcheck occurs in pthread_kill(). This results in a core dump. PROBLEM: (Patch ID: OSF410-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 per- formance 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, 44398) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-400372) ******** During the search for exception handlers, DECthreads unwound the stack and, in the process, removed the stack frame in which the exception occurred. The result was an incorrect stack trace with missing frames. PROBLEM: (QAR 55153) (Patch ID: OSF410-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 lock or 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 attempts 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: OSF410-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: (HPAQA0X6X) (Patch ID: OSF410-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 treaded 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 or more than 5,000,000 seconds. With the fix, pthread_cond_timedwait() can be called with any timeout value. PROBLEM: (QAR 56298) (Patch ID: OSF410-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: (QAR 48541) (Patch ID: OSF410-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: (GOZ100846) (Patch ID: OSF410-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: OSF410-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 multithreaded RPC client process catches a signal, a read or write to an RPC socket can get interrupted, and the RPC operation fails. PROBLEM: (QAR 56286) (Patch ID: OSF410-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: OSF410-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 not remove signal handlers until the termination of the process. PROBLEM: (QAR 57320) (Patch ID: OSF410-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 30442,53287,57097, CLD UVO105627) (Patch ID: OSF410-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: (HGOQ10179, QAR 58378) (Patch ID: OSF410-405179) ******** This patch fixes a problem with the syslog function. Some syslog messages may fail to get written to a log file when the system is experiencing a heavy I/O load. PROBLEM: (MGO103361/QAR 58563) (Patch ID: OSF410-405181) ******** This patch fixes a problem with rexec(3) losing socket descriptors. Applications that call rexec(3) may not work correctly. PROBLEM: (QAR 47388,51864,52427,58881) (Patch ID: OSF410-405191) ******** This patch fixes a problem with the statvfs function. statvfs returns a wrong status when the file system is full. PROBLEM: (QAR 59249) (Patch ID: OSF410-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 stacksize or guardsize. PROBLEM: (QAR 51557) (Patch ID: OSF410-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 51557) (Patch ID: OSF410-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: (HPAQ17931, HPAQA353A) (Patch ID: OSF410-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: OSF410-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: (QAR 59440) (Patch ID: OSF410-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: OSF410-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: (CLD MGO103500) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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 BRO101218 / QAR 61257) (Patch ID: OSF410-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: OSF410-405381) ******** This patch fixes a memory leak in the libc glob() function. PROBLEM: (QAR 62714) (Patch ID: OSF410-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: (QAR 61080) (Patch ID: OSF410-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 HPAQ51QQZ) (Patch ID: OSF410-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: OSF410-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: (QAR 59367) (Patch ID: OSF410-172) ******** This patch adds automatic detection of a cdfs file system for the mount(8) command. PROBLEM: (SSRT0546U, SSRT0542U) (Patch ID: OSF410-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: (UVO104297) (Patch ID: OSF410-400118) ******** This patch fixes a problem that occurs when using the Korn shell (ksh). Keyboard input is not echoed when a user exits via a trap, after editor options have been set in ksh. To restore the tty modes, enter the following command: stty sane To reproduce the problem execute the following: /usr/bin/ksh set -o emacs touch /tmp/foo trap 'rm -f /tmp/foo' EXIT TMOUT=1 Now wait 60 seconds. When ksh exits, the keyboard should echo characters. If it does not, then this bug has occurred. PROBLEM: (QAR 50297) (Patch ID: OSF410-400169) ******** The ksh shell program prevents a command, which runs in a sub-process, from writing to a tape device. For example: $ /usr/bin/ksh -c "/bin/echo foo | /bin/cat > /dev/rmt0h" /usr/bin/ksh: /dev/rmt0h: cannot create PROBLEM: (QAR 51086) (Patch ID: OSF410-057) ******** Set old-obreak = 0 breaks ksh will be fixed by this patch. PROBLEM: (QAR 26933) (Patch ID: OSF410-400270) ******** This patch fixes a problem in which the ksh command periodically prints erroneous characters instead of the command that was typed. The only identifiable effects are loss of logging information and the loss of access to the command from the command line edit. PROBLEM: (QAR 52892, 49928) (Patch ID: OSF410-400304) ******** This patch fixes a problem in which the ksh shell sometimes reverses the group id (GID) and the effective group id (egid) of the calling process. For example if the calling process (starter) spawns ksh to execute the "/usr/bin/id" command, the output would be: $ ./starter xx uid=4294967200(vsctest) gid=15(users) egid=4(bin) groups=0(system) uid=4294967200(vsctest) gid=4(bin) egid=15(users) groups=0(system) $ ### Note that the gid and egid have been interchanged PROBLEM: (HGOQ50006, QAR 52992) (Patch ID: OSF410-400326) ******** This patch fixes problems that occur when using the ksh shell. When the PATH for a command is not found, the following error message is displayed. Also, when the set command is executed, the system core dumps. /bin/ksh: invalid multibyte character PROBLEM: (USG-05628) (Patch ID: OSF410-400435) ******** This patch fixes a problem that occurs when using the Korn shell (ksh). Variables set with the typeset -L[n] built-in command do not work correctly when other subshells are spawned. For example: Example: < Incorrect results > $ /usr/bin/ksh $ typeset -xL3 var=hello $ typeset | grep var export 3 leftjust 3 var $ echo $var hel $ /usr/bin/ksh $ typeset -xL3 var=hello $ typeset | grep var export 3 leftjust 3 var $ echo $var $ Example: < Correct results > $ /usr/bin/ksh $ typeset -xL3 var=hello $ typeset | grep var export 3 leftjust 3 var $ echo $var hel $ /usr/bin/ksh $ typeset -xL3 var=hello $ typeset | grep var export 3 leftjust 3 var $ echo $var hel $ PROBLEM: (QAR 45801,QAR 61048,EVT102530) (Patch ID: OSF410-405301) ******** This patch fixes a problem that was caused by the Korn shell running in EMACS mode. When a window was resized with a width that exceeded 160 characters, the next command (or even a return) would cause the ksh utility to core dump. PROBLEM: (BCPM40XKX, 53066) (Patch ID: OSF410-405331) ******** This patch fixes a problem in the kornshell in which the "lt" operator didn't work correctly when the first expression was more than ten digits. PROBLEM: (CLD MGO103483) (Patch ID: OSF410-405343) ******** This patch fixes a problem when builtin variables (ex. TMOUT) are exported as readonly with values > 256. The 'set' command (display all variables) will cause ksh to core dump with the error "stack overflow". PROBLEM: (QAR 41085) (Patch ID: OSF410-400193) ******** Fixes a problem in which the :q history substitution modifier in csh may result in a syntax error. PROBLEM: (QAR 41087) (Patch ID: OSF410-400193) ******** Fixes a problem in which the :x history substitution modifier in csh may result in a syntax error. PROBLEM: (QAR 41746) (Patch ID: OSF410-400193) ******** Fixes a problem in which receipt of a SIGALRM signal by a child process of csh does not result in csh reporting the death of the child process with the message 'Alarm clock'. Instead the system displays the following message: auto-logout PROBLEM: (QAR 42250) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh erroneously jumps to the middle of an embedded if-then statement. This occurs upon reaching the end of a while loop, when the loop is entered manually, rather than executed from a script. PROBLEM: (QAR 43026, 45613, 47089, 47146, HPXQC14BV, HPXQC15ND) ******** (Patch ID: OSF410-400193) Fixes a problem in which an error in a file sourced by csh results in a logout of the csh process. PROBLEM: (QAR 44539) (Patch ID: OSF410-400193) ******** Fixes a problem in which the default value for prompt2 in csh is ">" instead of "?". PROBLEM: (QAR 46802) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh can core dump when expanding a large "*" pattern. PROBLEM: (QAR 45059) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh fails to do file name substitution on the result of a command substitution. PROBLEM: (QAR 46160, 47019, TKTQB1363) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh expands metacharacters (for example, "*") even when they are inside quoted strings. This problem can cause the grep, sed, and find commands to fail when "*" appears inside a quoted regular expression argument. PROBLEM: (QAR 45632) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh does not expand tilde ("~") in a path name that also contains a backquoted expression ("`...`"). PROBLEM: (QAR 47453) (Patch ID: OSF410-400193) ******** Fixes a problem in which the autologout feature of csh is by default enabled for pseudo ttys (for example, during an rlogin session). With this patch, autologout is enabled by default if csh runs as a login shell and if the standard input stream is not a pseudo tty and the DISPLAY environment variable is not set. Autologout under these conditions can be disabled by adding the following line to your .login or .cshrc file: set autologout = 0 If autologout is set to a value greater than 0 (zero), csh terminates if a command is not entered within the prescribed number of minutes after issuing the csh prompt. You can find out whether the autologout feature is enabled for the session by checking the value of $autologout. PROBLEM: (QAR 48250) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh can core dump while using the history facility when edit mode is set to emacs. PROBLEM: (QAR 46161) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh does not read the .cshrc and .login files in the user's home directory if they are not owned by the user and in the same group as the user. PROBLEM: (QAR 44298) (Patch ID: OSF410-400193) ******** Fixes a problem in which csh prints a misleading message ("No match") when a command line contains characters such as "*" or "?" and the user does not have read access to the current directory. With this patch, csh will print the more more descriptive message "Glob aborted - Permission denied". PROBLEM: (QAR 26082) (Patch ID: OSF410-400193) ******** Fixes a problem in which a csh loop that runs background processes exits when too many processes have been created. With this patch, csh works like ksh in that it waits for process creation to succeed. PROBLEM: (ZUO101309) (Patch ID: OSF410-400434) ******** This patch fixes a problem that occurs when using the C shell (csh). When a command that does both wildcard expansion and command substitution is run in csh, incorrect results are produced. For example: $ /usr/bin/csh $ ls *.c `ls *.h` *.c not found a.h b.h example: $ /usr/bin/csh $ ls *.c `ls *.h` a.c a.h b.c b.h PROBLEM: (CLD TKTQ20082) (Patch ID: OSF410-405159) ******** The data byte 0x80 is a valid second byte of a 2-byte character in the SJIS and BIG-5 character sets. However, this data byte also has special meaning within the C shell (csh). This leads, in some cases, to incorrect processing of multibyte characters that contain 0x80 as the second byte. For instance, under the ja_JP.SJIS locale, the following echo command produces the wrong result: % echo `printf "\217\200"` | od -xc 0000000 0a8f \n 0000002 This patch prevents the 0x80 data byte from being omitted. Using the new csh command included in the patch, the echo command returns the correct result: % echo `printf "\217\200"` | od -xc 0000000 808f 000a ** \n 0000003 Also by using the new csh, users can print out a single 0x80 character using the echo command. However, quoting is necessary to prevent unwanted removal of the 0x80 character. For example: % echo "`printf '\200'`" | od -xc 0000000 0a80 \n 0000002 % echo `printf '\200'` | od -xc 0000000 000a \n 0000001 PROBLEM: (UVO105992) (Patch ID: OSF410-405365) ******** This patch corrects a problem which results in a superuser being able to inadvertently bring the system down to single user mode by accidentally killing pid 1 (init) when trying to kill a background job (%1). PROBLEM: (CLDs HPAQ50F5M HPAQ21LTJ QAR 53389) (Patch ID: OSF410-405389) ******** File globbing in ksh sometimes does not list all the files in the directory. PROBLEM: (CLDs DMO100352 QAR 57030) (Patch ID: OSF410-405389) ******** This patch fixes a memory managment problem that occurs on systems running the Korn shell. Incorrect results occur when the length of the parameter to the echo command is altered. PROBLEM: (49941) (Patch ID: OSF410-400122) ******** Correct problems where quota program was not returning most severe error as exit status. PROBLEM: (HPXQ72698, STLQ80579, HPXQ89BA1) (Patch ID: OSF410-400079) ******** The dump command fails when it is run through a pipe. The program will fail with the following error message: available blocks n < estimated blocks m PROBLEM: (HPXQ65A29) (Patch ID: OSF410-400079) ******** When using the rdump command to dump to a regular file or to dump to a system whose uname command does not report OSF or ULTRIX, the command fails. The program will fail with the following error message: available blocks n < estimated blocks m PROBLEM: (HPXQ7269D) (Patch ID: OSF410-400079) ******** When a member of group "operator" logged into the console and (r)dump was invoked with the -n flag, an extraneous file (/dev/:0) was created. PROBLEM: (QAR 55069) (Patch ID: OSF410-400382) ******** This patch fixes a problem in which the dump command fails when the full pathname of the output file is not given. The following is an example of a failed dump command: #dump -f dufile /mnt1 dump: Dumping from host shuka.xko.dec.com dump: Date of this level 9 dump: Fri Sep 19 10:26:50 1997 GMT+0500 dump: Date of last level 0 dump: the start of the epoch dump: Dumping /dev/rrz0h (/mnt1) to dufile dump: Mapping (Pass I) [regular files] dump: Mapping (Pass II) [directories] dump: Estimate: 205666 tape blocks on disk The available blocks(0),is less than the estimated blocks(205666) Dump is being aborted dump: SIGTERM received dump: The ENTIRE dump is aborted PROBLEM: (QAR 56531 QAR 56516 QAR 56530 QAR 56529) (Patch ID: OSF410-400437) ******** Commands vquota, vedquota, quota, edquota, dump, csh, and nslookup will sometimes display the incorrect error message for non-english locales. PROBLEM: (BCGM41776, QAR 63443) (Patch ID: OSF410-405422) ******** This patch fixes a problem with the edquota utility, which prevented a user from creating quotas for UIDs or GIDs that did not already exist in the /etc/passwd or /etc/group files. PROBLEM: (CLD's BCGMC1GJ4, HPAQC1L0D, HPAQC1L10) (Patch ID: OSF410-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 63603) (Patch ID: OSF410-405477) ******** This patch fixes a problem in the csh shell that caused a change in the way wildcard patterns were matched. The problem resulted in the error: Glob aborted - Permission denied. PROBLEM: (EVT102702, QAR 61875/64784) (Patch ID: OSF410-405479) ******** This patch fixes a problem with /usr/bin/ksh and the named-pipe (FIFO) communication that is used by applications. This problem is seen randomly when 2 shells scripts (a parent process and a child process) are waiting for each others read/write on their named-pipe. It was observed that the read didn't complete by the child process although data was present in its named-piped writen by the parent process. PROBLEM: (SSRT0588U) (Patch ID: OSF410-405549) ******** 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. Compaq has corrected this potential vulnerability. PROBLEM: (CLD's BCGM10PM6 and DMO100420) (Patch ID: OSF410-405564) ******** This patch fixes a problem from a previous libc patch in which the gethostbyaddr function is not able to resolve node names. Non-standard characters that fall out of the standard set, such as underscores, cause a node name resolution problem for the gethostbyaddr function. PROBLEM: (TKTQ90857) (Patch ID: OSF410-405586) ******** This patch fixes a problem where C shell background processes started from within a terminal emulator window (dtterm, dxterm, or xterm) exit when the terminal emulator window is closed. PROBLEM: (QAR 65164) (Patch ID: OSF410-405538) ******** This problem fixes unexpected logouts and terminal hangups encountered when using the /bin/su command and /bin/ksh as a login shell. PROBLEM: (CLD BCGM71LG7) (Patch ID: OSF410-405528) ******** This patch corrects a problem that was causing ksh to core dump in vi editting mode. ksh was core dumping intermittently when using '.' to repeat a command. PROBLEM: (CLD MGO103997) (Patch ID: OSF410-240) ******** This patch fixes a problem with ksh. ksh will core dump with segmentation fault when displaying a here-document. PROBLEM: (SSRT0496U) (Patch ID: OSF410-400343) ********* 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 58332, QAR 59467) (Patch ID: OSF410-405201) ******** This patch fixes the mount command. An incorrect error message is displayed when trying to mount a directory, which does not exist, under a valid exported file system. PROBLEM: (MCPM212FV) (Patch ID: OSF410-405227) ******** This patch fixes a problem in mountd where lines in the /etc/exports file could be no longer than 1023 characters. With this patch, a trailing backslash character in the /etc/exports file allows continuations beyond 1023 characters. PROBLEM: (QAR 65033, QAR 61856, QAR 64040, SSRT0563U) (Patch ID: OSF410-405500) ******** This patch fixes a problem in mountd. The NFS server allows read/write access to clients not on the exports list and other clients to be incorrectly denied access. PROBLEM: (QAR 62614) (Patch ID: OSF410-217) ******** This patch fixes a problem with the mount command where it sometimes kills other processes. This randomly occurs if the file where mound stores its pid, /var/run/mountd.pid, is out-of-date. PROBLEM: (QAR 65597) (Patch ID: OSF410-223) ******** This patch addresses a problem with the shutdown script on a client server, when run from rsh using the -h or -r flags. The system being shutdown returns appropriate messages to the console, it however never shuts down but appears to hang, preventing any further user interaction such as rlogin or rsh. This patch is MANDATORY. This patch needs to be installed on all client and servers.