PROBLEM: (QAR 58234) (Patch ID: OSF425-405315) ******** When the system was shut down to single user mode, kloadsrv was halted. This fix ensures that kloadsrv remains running by ignoring the SIGTERM signal. PROBLEM: (63287) (Patch ID: OSF425-383) ******** This patch fixes a problem with dbx when debugging programs that have large source files. In some cases dbx may abort with a segmentation fault. This may happen at startup, or when execution moves into a routine in a new source file. PROBLEM: (QAR 58479) (Patch ID: OSF425-254) ******** This patch fixes a dbx problem with listing a large Fortran program that contains alternate entry points. If the source code is broken down into a number of subroutines, and the user requests, in dbx, to print line 1000, dbx reports that 1000 is beyond the end of the file, when in fact it is not. PROBLEM: (QAR 60922, QAR 55002, QAR 46115) (Patch ID: OSF425-278) ******** This patch fixes an AdvFS problem that occurs when the rmvol command is stopped before the commmand successfully removes a volume from a domain. As a result, the showfdmn and addvol commands interpreted the volume as still in the domain (although with no data available) and a balance operation returned the following AdvFS error message: get vol params error EBAD_VDI (-1030) PROBLEM: (QAR 65348 and QAR 65349 and QAR 65803) (Patch ID: OSF425-449) ******** This patch fixes three /usr/sbin/lmf date problems. 1) LMF improperly handles 2-digit dates between 2000 and 2068. 2) When LMF is given two consequtive commands and the first command contains a leap year date, then the date for the second command is automatically assumed to be in a leap year. 3) LMF does not recognize the date 29-FEB-2000. Here are two simple tests to demonstrate the problems and the fixed behavior. The first problem can be shown with the following command: # lmf cancel 10-APR-00 OSF-USR Invalid argument 10-apr-00 Usage : lmf cancel [ [ ] ] The corrected behavior is shown with the following command: # ./lmf cancel 29-FEB-2000 OSF-USR # PROBLEM: (QAR 57968, QAR 59034, QAR 67964) (Patch ID: OSF425-405575) ******** This patch fixes the following problems: - segmentation fault in /sbin/loadsrv - In the License Management Facility, incorrect amount of memory is copied, which potentially can cause data corruption. PROBLEM: (None) (Patch ID: OSF425-536) ******** This patch is required for users who wish to view user stacktraces from full crash dumps with dbx. PROBLEM: (CLD BCSM1214J, QAR 69696) (Patch ID: OSF425-642) ******** This patch corrects a problem where the /sbin/kloadsrv process may hang and not respond to /usr/sbin/netstat commands. When this occured, the error reported by netstat was 'no namelist'. PROBLEM: (CLD HPAQ5131P) (Patch ID: OSF425-675) ******** This patch fixes a problem in viewing a variable subrange parameter from a pascal module while using dbx. While trying to view a particular parameter type, dbx truncates the address, and gives the error "can't read from process (address 0xffff)" The following Pascal program is an example that demonstrates the problem. PROGRAM dbx_word_err(output); TYPE word = [WORD] 0..65535; VAR chn : word; PROCEDURE test(VAR chan: word); VAR blah : word; BEGIN blah := 5; chan := blah + 100; END; BEGIN test(chn); END. The following dbx session illustrates the problem: dbx dbx_work_err dbx version 3.11.10 Type 'help' for help. DBX_WORD_ERR: 20 test(chn); (dbx) stop in test [2] stop in TEST (dbx) r [2] stopped at [TEST:15 ,0x120001ccc] blah := 5; (dbx) p chan can't read from process (address 0xfd00) PROBLEM: (MGO103900) (Patch ID: OSF425-630) ******** This patch corrects a problem in AdvFS where unmounting a domain that is already in a panicked state could result in the following system panic message: log_flush_sync: pinpg error\n N1 = 5 Note: In this instance an I/O error (EIO = 5) caused the original domain panic. Stack trace: 6 advfs_sad() 7 log_flush_sync() 8 lgr_writev_ftx() 9 log_donerec_nunpin() 10 ftx_done_urdr() 11 ftx_done_n() 12 quota_deactivate() 13 msfs_unmount() Kernel Rebuild required. PROBLEM: (QARS 61528 61453 61531 61552) (Patch ID: OSF425-654) ******** This patch fixes problems in the AdvFS verify command as follows: Changes to error messages given when the AdvFS utility verify(8) detects mcells that are marked as belonging to a file, but not linked into its mcell chains. The new message warns of metadata corruption as follows: Metadata corruption in the BMT of disk 3: found mcell labelled as belonging.... The patch also corrects a problem whereby "verify -d" was unable to delete files with no directory entries. PROBLEM: ('QAR 69227, QAR 69352') (Patch ID: OSF425-826) ******** This patch fixes a problem with multi-volume domains with large frag files. Verify complains about frag pages that are in sparse holes and therefore will be read as a page of zeros causing the domain to appear as if it was corrupt. PROBLEM: (52718, 74111, 61261) (PATCH ID: OSF425-931) ******** Problem 1: Dbx stack trace is incomplete. In certain cases, dbx's 'where' command did not produce a complete stack trace. This was seen when debugging at the assembly level and using the 'stepi' command to step into a routine, or when there is a fault in some library routines. The following shows some instances of the problem. Stepping into a routine with stepi ('si'), Getting a stack trace ('where' or 't') Attempt to 'return' >*[main:68, 0x1200018b0] ldq r27, -32568(gp) (dbx) ni >*[main:68, 0x1200018b4] jsr r26, (r27), 0x120005e60 (dbx) si >*[_OtsMove, 0x3ff800d5e60] amask 0x1, r19 (dbx) t > 0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60] (dbx) return no place to return to (dbx) up (dbx) t > 0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60] Stepping into a routine until the stack is correct >*[main:68, 0x1200018cc] ldq r21, 40(r8) (dbx) ni >*[main:68, 0x1200018d0] bsr r26, recurse+0x8(line 29) (dbx) si >*[recurse:29, 0x120001638] ldq r28, -16448(sp) (dbx) t > 0 recurse(inbox = (...)) ["crashit.c":29, 0x120001638] (dbx) ni >*[recurse:29, 0x12000163c] ldq r28, -4096(sp) (dbx) ni >*[recurse:29, 0x120001640] ldq r28, -12256(sp) (dbx) ni >*[recurse:29, 0x120001644] lda sp, -16448(sp) (dbx) ni >*[recurse:29, 0x120001648] stq r26, 8144(sp) (dbx) t > 0 recurse(inbox = (...)) ["crashit.c":29, 0x120001648] (dbx) ni >*[recurse:29, 0x12000164c] stq r16, 16400(sp) (dbx) t > 0 recurse(inbox = (...)) ["crashit.c":29, 0x12000164c] 1 main(argc = 3, argv = 0x11ffffce8) ["crashit.c":68, 0x1200018d0] Problem 2: Dbx cannot set a variable after viewing a non-local variable: Dbx has several methods of looking for variables. If the variable is not found in the current routine, active procedures on the stack are searched, and then global variables are searched. When dbx searched up the stack for the variable, it failed to reset an internal pointer an assignment to a local variable failed. main: 52 if (argc < 3) { (dbx) stop in justtryme [2] stop in justtryme (dbx) r 0 3 [2] stopped at [justtryme:21 ,0x1200015d4] deepend = levels; (dbx) n [justtryme:23 ,0x1200015d8] printf("Cpu %d going down, stack about %d levels deep\n", cpu, deepend); (dbx) p iter /* A variable local to the main routine 3 (dbx) assign deepend = 10 10 (dbx) p deepend 3 (dbx) q Problem 3: Dbx receives signal 66 on vfork: When debugging a program that executes a vfork, dbx exhibited this: dbx version 3.11.10 Type 'help' for help. main: 11 signal( SIGCHLD, handler ); (dbx) r signal [signal 66] at >*[__vfork, 0x3ff800e7968] beq r19, 0x3ff800e7980 (dbx) The correct behaviour follows: main: 11 signal( SIGCHLD, handler ); (dbx) r New child attached. Use switch to gain access to process 5774 child: 5774 (dbx) PROBLEM: (TKTBC0129, 74469) (PATCH ID: OSF425-1092) ******** This patch fixes problems with the dbx kernel debug option when used on kernel core files from wildfire and other large memory systems.