TITLE: DUNIX duv40bas00004-19970808 for DUNIX V4.0B Aggregate ECO Summary
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
PRODUCT: Digital UNIX [R] V4.0B
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Name: DUV40BAS00004-19970808
ECO Superseded by This ECO: DUV40BAS00004-19970609
All previously released Official
Digital UNIX V4.0B patches
ECO Kit Approximate Size: 35MB
Kit Applies To: Digital UNIX V4.0B
ECO KIT SUMMARY:
This patch kit is a re-release of Digital UNIX V4.0B Patch Kit 0004. Several
patches were updated, as well as the patch management utility. We recommend
that this re-released kit be installed on all systems on which the previous
patch kit was installed. Please refer to the release notes for more
information.
This is the aggregate, setld-based, patch kit for Digital UNIX V4.0B. It
is a cumulative patch kit that contains all patches that were available for
distribution in April/May 1997. The patch kit provides the ability to
selectively install patches.
The Release Notes and Installation Instructions document provides patch kit
installation and removal instructions and a summary of each patch. Please read
through the document prior to installing patches on your system.
Note:
At this time, the release note/installation document is only available in
postscript form. It will be available in text and HTML formats in the future.
INSTALLATION NOTES:
Install this kit with the dupatch utility that is included in the patch kit.
The Release Notes and Installation Instructions document provides detailed
patch installation, patch removal, and a summary of each patch. You may
need to baseline your system if you have manually changed system files on
your system. The dupatch utility provides the baselining capability.
KNOWN PROBLEMS WITH THE PATCH KIT:
None.
[R] UNIX is a registered trademark in the United States and other countries
licensed exclusively through X/Open Company Limited.h
Copyright Digital Equipment Corporation 1997. All Rights reserved.
This software is proprietary to and embodies the confidential technology
of Digital Equipment Corporation. Possession, use, or copying of this
software and media is authorized only pursuant to a valid written license
from Digital or an authorized sublicensor.
This ECO has not been through an exhaustive field test process.
Due to the experimental stage of this ECO/workaround, Digital
makes no representations regarding its use or performance. The
customer shall have the sole responsibility for adequate protection
and back-up data used in conjunction with this ECO/workaround.
===============================================================================
On systems with PCXAL, LK411, and similar keyboards, sometimes the keyboard
stops working.
PROBLEM: (TKTB49381,GOZ100613,UTO101179) (Patch ID: OSF410-035)
********
On systems with PCXAL, LK411, and similar keyboards, sometimes on boot or
between sessions on the workstation monitor, the keyboard stops working.
FILE(s):
/sys/BINARY/gpc.mod subset OSFHWBIN410
CHECKSUM: 45770 18
/sys/BINARY/gpc_input.mod subset OSFHWBIN410
CHECKSUM: 52565 30
===============================================================================
Issuing a SET_DEVICE_MODE ioctl to the workstation driver to change cursor
reporting to relative mode fails.
PROBLEM: (QAR 49961) (Patch ID: OSF410-038)
********
Issuing a SET_DEVICE_MODE ioctl to change the reporting of the cursor
position from absolute mode to relative mode fails. The ioctl is not
being handled correctly by the workstation driver.
FILE(s):
/sys/BINARY/ws.mod subset OSFHWBIN410
CHECKSUM: 39282 97
===============================================================================
The S3 Trio64V+ graphics card is not being correctly identified by the driver
at startup.
PROBLEM: (QAR 50202) (Patch ID: OSF410-042)
********
The S3 Trio64V+ graphics card is not being correctly identified by the driver
at startup.
FILE(s):
/sys/BINARY/s3trio.mod subset OSFHWBIN410
CHECKSUM: 26712 43
===============================================================================
This patch fixes problems that occur with the dump and rdump commands.
The commands will fail with the following error message:
available blocks n < estimated blocks m
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: (HPXQ72698,STLQ80579,HPXQ89BA1) (Patch ID: OSF410-400079)
********
o 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)
********
o 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)
********
o 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.
FILE(s):
/usr/sbin/dump subset OSFHWBASE410
CHECKSUM: 38814 80 RCSfile: dump.h RCS: 4.2.42.2
RCSfile: dump.msg RCS: 4.2.30.2
RCSfile: dumpmain.c RCS: 4.2.43.2
RCSfile: dumpoptr.c RCS: 4.2.24.2
RCSfile: dumptape.c RCS: 4.2.46.2
/sbin/dump subset OSFHWBASE410
CHECKSUM: 35642 80
/usr/lib/nls/msg/en_US.ISO8859-1/dump.cat subset OSFHWBASE410
CHECKSUM: 30558 10
/usr/sbin/rdump subset OSFCLINET410
CHECKSUM: 33611 80
===============================================================================
This patch fixes the problem of the math library functions not returning
the correct NaN value as defined in the Alpha AXP Architecture Reference
Manual (Second Edition).
PROBLEM: (QAR 48474) (Patch ID: OSF410-400083)
********
This fix changes the encoding of IEEE floating-point Quiet NaNs returned by
the math library by setting the sign bit.
This fix corrects inconsistency between the value returned by the math functions
and the kernel encoding.
A NaN is the floating-point representation of a result that is "Not a Number"
(e.g. the floating-point result of zero divided by zero is a NaN).
This change is only of interest to programmers who use IEEE floating-point math
with the -ieee or the -ieee_with_inexact opion. It does not affect programs
or libraries not using the full IEEE math support.
For more information, see the IEEE Standard for Binary Floating Point Arithmetic
ANSI/IEEE (Std 754-1985). For information about the Alpha AXP implementation,
see the Alpha AXP Architecture Reference Manual (Second Edition) by
Richard L. Sites and Richard T. Witek, Digital Press, 1995. See the section
on "Encodings" (4.7.4).
Compile the following program using the -ieee and -lm options:
#include
#include
#include
#include
main()
{
double a, b, c, d;
int i;
a = sqrt( -1.0 );
i = sscanf("0.0 0.0 0.0", "%lf %lf %lf", &b, &c, &d);
assert(i == 3);
printf( "sqrt( -1.0 ) = %f\t\t0x%016lx\n", a, *(long *)&a );
d = b / c;
printf( "0.0 / 0.0 = %f\t\t0x%016lx\n", d,*(long *)&d );
}
Compile this program using the -ieee and -lm command line options.
Results before installing new math library:
sqrt( -1.0 ) = NaNQ 0x7fffffffffffffff
0.0 / 0.0 = -NaNQ 0xfff8000000000000
Results after installing new math library:
sqrt( -1.0 ) = -NaNQ 0xfff8000000000000
0.0 / 0.0 = -NaNQ 0xfff8000000000000
FILE(s):
/usr/ccs/lib/libm.a subset OSFLIBA410
CHECKSUM: 38043 660
/usr/shlib/libm.so subset OSFBASE410
CHECKSUM: 63782 544
===============================================================================
Correct quota command to return most severe error status on exit.
PROBLEM: (49941) (Patch ID: OSF410-400122)
********
Correct problems where quota program was not returning most severe error as
exit status.
FILE(s):
/usr/sbin/quota subset OSFBASE410
CHECKSUM: 56103 40 RCSfile: quota.c RCS: 4.2.44.2
RCSfile: rquotaxdr.c RCS: 4.2.4.2
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat subset OSFBASE410
CHECKSUM: 60092 1
===============================================================================
This patch fixes a "kernel memory fault" in the dqget() routine.
PROBLEM: (HPAQ92E5E) (Patch ID: OSF410-400126)
********
This patch fixes a "kernel memory fault" in the dqget() routine. The crash
signature will look like the following:
0 boot() [../../../../src/kernel/arch/alpha/machdep.c]
1 panic(kernel memory fault) [../../../../src/kernel/bsd/subr_prf.c]
2 trap() [../../../../src/kernel/arch/alpha/trap.c]
3 _XentMM() [../../../../src/kernel/arch/alpha/locore.s]
4 dqget() [../../../../src/kernel/ufs/ufs_quota.c]
5 quota_chown() [../../../../src/kernel/ufs/ufs_quota.c]
6 chown1() [../../../../src/kernel/ufs/ufs_vnops.c]
7 ufs_setattr() [../../../../src/kernel/ufs/ufs_vnops.c]
8 chown2() [../../../../src/kernel/vfs/vfs_syscalls.c]
9 chown() [../../../../src/kernel/vfs/vfs_syscalls.c]
10 syscall() [../../../../src/kernel/arch/alpha/syscall_trap.c]
11 _Xsyscall() [../../../../src/kernel/arch/alpha/locore.s]
FILE(s):
/usr/sys/BINARY/ufs_quota.o subset OSFBIN410
CHECKSUM: 44578 79 RCSfile: ufs_quota.c RCS: 4.2.32.2
===============================================================================
This patch fixes a panic which occurs when a UNIX domain socket lock is being
held while calling vrele().
PROBLEM: (QAR 49023) (Patch ID: OSF410-400130)
********
A "panic: lock_read: hierarchy violation in del_dealloc_stg" error occurs when
a socket lock is held by a UNIX domain while calling vrele().
FILE(s):
/sys/BINARY/uipc.mod subset OSFBIN410
CHECKSUM: 08259 21
===============================================================================
STREAMS tty line discipline was not correctly processing type-ahead characters.
PROBLEM: (QAR 50783) (Patch ID: OSF410-048)
********
Under some circumstances type ahead characters are not processed if a new line
is not entered. This is prevalently seen on screen tools which switch from
canonical mode (line process mode) to raw mode.
FILE(s):
/sys/BINARY/ldtty.mod subset OSFBIN410
CHECKSUM: 64956 131
===============================================================================
This patch fixes a problem in which the output of the "last" or "finger"
command lists users that are not currently logged in.
PROBLEM: (CLD UVO104899) (Patch ID: OSF410X11-400010)
********
This patch fixes a problem in which the output of the "last" or "finger"
command lists users that are not currently logged in.
This patch fixes the error by ensuring that the username field is cleared from
the wtmp file when the user exits from an xterm process.
FILE(s):
/usr/bin/X11/xterm subset OSFX11410
CHECKSUM: 17810 216
===============================================================================
Systems with an S3 Trio64 graphics card can loose time (on the order of a few
minutes a day).
PROBLEM: (QAR 51230) (Patch ID: OSF410X11-400011)
********
Systems with an S3 Trio64 graphics card can loose time (on the order of a few
minutes a day).
FILE(s):
/usr/shlib/X11/lib_dec_s3.so subset OSFSERPC410
CHECKSUM: 19011 160
===============================================================================
SUPERSEDED PATCHES: OSF410-400092 (13.00)
This patch corrects the following:
- Fixes a problem that causes the system to "assert_wait" panic and the stack
contains streams modules.
- A problem where a remote user will kill rlogin or telnet and the server host
will have an orphanned login process and rlogind or telnetd process in sleep
state indefinitely. This is seen only with Asian tty (atty) or any other
host which is running c-list rather than STREAMS tty's.
PROBLEM: (TKTR70408, QAR 47306) (Patch ID: OSF410-400092)
********
This problem affects only Digital UNIX systems using C-list-type tty's.
If a user attempts to log into such a system remotely, using either telnet
or rlogin, and kills the remote-access application (telnet or rlogin) during
the login procedure (at the "Password:" prompt) then the rlogind or telnetd
process will be left in a sleep state indefinitely. This condition can be
recognized by the presense of rlogind or telnetd processes in the process table
with no associated remote user.
PROBLEM: (HPAQ95241, QAR 50022) (Patch ID: OSF410-405042)
********
This patch fixes a problem that causes the system to "assert_wait" panic and
the stack contains streams modules.
A representative stack trace is:
panic(s = "assert_wait")
assert_wait_mesg sched_prim.c
pts_close pty.c
close_wrapper str_subr.c
csq_protect str_synch.c
osr_pop_subr str_osr.c
osr_close_subr str_scalls.c
pse_close str_scalls.c
speclose spec_vnops.c
clearalias spec_vnops.c
exit kern_exit.c
psig kern_sig.c
trap trap.c
FILE(s):
/sys/BINARY/pty.mod subset OSFBIN410
CHECKSUM: 46701 20
===============================================================================
This patch fixes a problem with the ftp command. If you ftp to an IBM MVS
system using the IP address, the IBM system will refuse the connection.
This problem can be encountered on any system that validates TOS (Type Of
Service) requests if the file /etc/iptos is not used on the client.
PROBLEM: (MCPMC0L3C/QAR 50410) (Patch ID: OSF410-400144)
********
Problem - If you ftp to an IBM MVS system using the IP address, the IBM system
will refuse the connection.
This problem can be encountered on any system that validates TOS (Type Of
Service) requests if the file /etc/iptos is not used on the client.
How to recognize this problem:
If you attempt to ftp to any system that validates TOS requests, you may see
the following:
ftp> open
Connected to
220-FTPSERV1 IBM MVS V3R1 at SAC1, 12:08:49 on 1996/12/11
421 Service not available, remote server has closed connection
but it may work if you give the hostname of the system instead of the
ip address.
If you were running tcpdump, tracing the connection, you would see
12:26:20.076128 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: S
1419648000:1419648000(0)
win 32768 (DF)
12:26:20.176656 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: S
447244900:447244900(0)
ack 1419648001 win 65535
12:26:20.176656 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 1 win 33580 (DF)
12:26:20.274256 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: P
1:60(59) ack 1 win 65535
12:26:20.366000 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 60 win 33580 (DF)
[tos 0xa6] <<<<<----NOTICE THIS!!!
12:26:20.461648 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: R
447244960:447244960(0) win 0
In the above trace, the connection is rejected because the TOS (Type Of
Service) field contains an invalid value. This problem can be avoided by
using a /etc/iptos file as noted in the man page. However, the TOS field
should never have this invalid value and that is the reason for the patch.
FILE(s):
/usr/bin/ftp subset OSFCLINET410
CHECKSUM: 63471 120 RCSfile: ftp.c RCS: 4.2.35.2
===============================================================================
This patch fixes a problem where telnet dumps core if the USER environment
variable is the last variable in the enviroment list.
PROBLEM: (FNO100131, QAR 43995) (Patch ID: OSF410-400150)
********
This patch fixes a problem where telnet dumps core if the USER environment
variable is the last variable in the enviroment list.
FILE(s):
/usr/bin/telnet subset OSFCLINET410
CHECKSUM: 58935 136 RCSfile: telnet.c RCS: 4.2.6.2
===============================================================================
This patch fixes a mutex lock problem in TLI. The problem causes multi-threaded
TLI applications to block forever.
PROBLEM: (QARs 49922 and 48633) (Patch ID: OSF410-400151)
********
Multithreaded TLI application blocks forever. dbx session will show that
it blocks in the t_look() library routine.
For this to happen, it is necessary that t_look() is called twice. Because it
is called internally by a number of other TLI library routines, application can
hang under all sorts of scenarios.
FILE(s):
/usr/ccs/lib/libtli.a subset OSFLIBA410
CHECKSUM: 01898 80
/usr/shlib/libtli.so subset OSFBASE410
CHECKSUM: 29583 80
/usr/ccs/lib/libxnet.a subset OSFLIBA410
CHECKSUM: 33792 68
/usr/ccs/lib/libxti.a subset OSFLIBA410
CHECKSUM: 33792 68
/usr/shlib/libxnet.so subset OSFBASE410
CHECKSUM: 45264 64
/usr/shlib/libxti.so subset OSFBASE410
CHECKSUM: 45264 64
===============================================================================
This patch fixes a problem that may cause /sbin/loader to fail to resolve
duplicate symbols in dlopen'ed shared libraries.
PROBLEM: (ULC-60, USG-04340, 50807) (Patch ID: OSF410-400152)
********
This patch fixes a problem that may cause /sbin/loader to fail to resolve
duplicate symbols in dlopen'ed shared libraries. Duplicate symbols only exist
in large multi-GOT objects. The application's dlopen call may get a
segmentation violation and there may be no traceback information.
Application developers may consider linking their application against the
multi-GOT shared libraries as a test for this problem. Statically loading the
libraries should work.
More information on multi-Got objects can be obtained from the odump man page
and the Assembly Language Programmer's Guide.
FILE(s):
/sbin/loader subset OSFBASE410
CHECKSUM: 61873 136
===============================================================================
SUPERSEDED PATCHES: OSF410-400160 (49.00)
This patch corrects the following:
- A potential security vulnerability has been discovered with the sendmail
command, where under certain circumstances, users may gain unauthorized access.
Digital has corrected this potential vulnerability.
PROBLEM: (SSRT0421U, QAR 49337) (Patch ID: OSF410-400160)
********
A potential security vulnerability has been discovered with the sendmail
command, where under certain circumstances, users may gain unauthorized access.
Digital has corrected this potential vulnerability.
FILE(s):
/usr/sbin/sendmail subset OSFBASE410
CHECKSUM: 26013 200
/usr/sbin/mailq subset OSFBASE410
CHECKSUM: 26013 200
/usr/sbin/newaliases subset OSFBASE410
CHECKSUM: 26013 200
/usr/sbin/smtpd subset OSFBASE410
CHECKSUM: 26013 200
/usr/var/adm/sendmail/.mrg..sendmail.cf subset OSFBASE410
CHECKSUM: 34462 5 RCSfile: .mrg..sendmail.cf RCS: 1.1.10.2
/usr/var/adm/sendmail/.new..sendmail.cf subset OSFBASE410
CHECKSUM: 12224 21
===============================================================================
This patch fixes a problem in which setting full duplex mode on DEFPA using
"/usr/sbin/fddi_config -i fta0 -x1" will not enable full duplex mode.
PROBLEM: (HPAQ82D5D) (Patch ID: OSF410-400166)
********
This patch fixes a problem in which settting full duplex mode on DEFPA using
"/usr/sbin/fddi_config -i fta0 -x1" will not enable full duplex mode.
FILE(s):
/usr/sbin/fddi_config subset OSFCLINET410
CHECKSUM: 58722 16 RCSfile: fddi_config.c RCS: 1.1.10.2
===============================================================================
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: (SSRT0448U, QAR 51211) (Patch ID: OSF410-400167)
********
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.
FILE(s):
/usr/sbin/ftpd subset OSFCLINET410
CHECKSUM: 02905 104 RCSfile: ftpd.c RCS: 4.2.41.2
RCSfile: ftpd_syslog.c RCS: 1.1.4.2
===============================================================================
This patch fixes a problem in which "netstat -I fta0 -s" reports 6 bytes of
the 8 byte "Station UID" and "Station ID".
PROBLEM: (HPAQ82D5D) PATCH ID: OSF410-400168
********
This patch fixes a problem in which "netstat -I fta0 -s" reports 6 bytes of
the 8 byte "Station UID" and "Station ID".
FILE(s):
/usr/sbin/netstat subset OSFHWBASE410
CHECKSUM: 38571 112
===============================================================================
This patch fixes two problems that occur on systems with an EISA bus:
- A system running four DE425 adapters off an EISA bus may hang.
- If a device's EISA configuration file contains a function DISABLE keyword
and the DISABLE option is selected, the device's driver may not be
configured and probed at bus configuration time.
PROBLEM: (EVT101968) (Patch ID: OSF410-400170)
********
A system that boots and runs OK with 3 DE425s on an eisa bus may hang during
boot if a 4th DE425 is added to the bus. The last message printed to the
screen during boot is "eisa at pci0" or something similar, and then the system
hangs. It does not respond to the halt button.
PROBLEM: (Patch ID: OSF410-400170)
********
When devices with a "disable" feature are used, the ECU table must be modified
manually when a device function is set to "disabled" because the system does
not detect the change.
FILE(s):
/sys/BINARY/eisa.mod subset OSFHWBIN410
CHECKSUM: 12297 71
===============================================================================
This patch fixes two problems with the mailx command.
PROBLEM: (UVO105070, QAR 50239) (Patch ID: OSF410-400172)
********
This patch fixes a problem with the mailx command. An error occurs when
replying to a message in which the "CC:" field contains blank-separated
names not enclosed in angle brackets ("<...>").
When replying to mail using lowercase "r", the "CC:" field on the reply
lists all blank-separated names after all enclosed angle bracket addresses.
The following error message is displayed:
... User unknown
PROBLEM: (QAR 45357) (Patch ID: OSF410-400172)
********
This patch provides a way for the mailx command to display the next message
instead of redisplaying the current message (default behavior).
When you press the Return key while reading mail, the default behavior for
mailx is to redisplay the current message. This patch provides a new variable,
"gonext", which allows you to read the next message. You can set the "gonext"
variable in the .mailrc file or at the mailx prompt using the "set gonext"
command. Setting the "gonext" variable in the .mailrc file makes the change
permanent. Setting the "gonext" variable at the mailx prompt means the "gonext"
variable is only valid for the duration of the current mail session.
FILE(s):
/usr/bin/mailx subset OSFBASE410
CHECKSUM: 19612 208
/usr/bin/Mail subset OSFBASE410
CHECKSUM: 19612 208
===============================================================================
This patch fixes a problem where use of "ld -r" will change symbol preemption
behavior.
PROBLEM: (QAR 49301) (Patch ID: OSF410-400174)
********
This patch fixes a problem where use of "ld -r ..." will change symbol
preemption behavior.
Without this patch, some global relocations can be converted to locals as an
optimization. These locals cannot be preempted.
An undocumented linker option has been added in the patched linker to prevent
this conversion. This new switch is "ld -no_local_conversion ..."
FILE(s):
/usr/ccs/lib/cmplrs/cc/ld subset OSFBASE410
CHECKSUM: 27007 824 RCSfile: ld.c RCS: 4.3.87.4
RCSfile: uldgnum.c RCS: 1.1.13.2
RCSfile: ldgetname.c RCS: 4.3.5.2
RCSfile: lderr.c RCS: 1.1.2.2
RCSfile: ldr_atexit.c RCS: 4.2.11.4
RCSfile: schyield.s RCS: 1.1.2.2
RCSfile: ldr_dummy.c RCS: 4.2.11.3
RCSfile: ldr_status.c RCS: 4.2.8.3
RCSfile: ldr_load.c RCS: 1.1.3.5
===============================================================================
SUPERSEDED PATCHES: OSF410-405043 (60.00)
This patch corrects the following:
- This patch fixes a Token Ring transmission timeout. The driver can experience
"ID 380PCI20001 (8/13/95)" in the TI380PCI Errata on the AlphaServer 4100
platform.
PROBLEM: (HPAL83FE3) (Patch ID: OSF410-405043)
********
This patch fixes a Token Ring transmission timeout.
The driver can experience "ID 380PCI20001 (8/13/95)" in the TI380PCI Errata
on the Alpha platforms.
FILE(s):
/sys/BINARY/tra.mod subset OSFHWBIN410
CHECKSUM: 07407 68
===============================================================================
On systems with an ATI Mach64 graphics card, sometimes the monitor will lose
synchronization or become stuck in power-save mode.
PROBLEM: (TKTB71151, TKTB64248) (Patch ID: OSF410X11-405005)
********
On systems with an ATI Mach64 graphics card, sometimes the monitor will lose
synchronization or become stuck in power-save mode.
FILE(s):
/usr/shlib/X11/lib_dec_ati64.so subset OSFSERPC410
CHECKSUM: 44372 128
/usr/shlib/X11/lib_dec_ws.so subset OSFSER410
CHECKSUM: 33115 112
/usr/shlib/X11/libextdpms.so subset OSFSER410
CHECKSUM: 63578 32
===============================================================================
Users appear to be logged in when they are not because CDE dtterm sometimes
doesn't reset the utmp entry on exit.
PROBLEM: (CLD ISO100270) (Patch ID: OSF410CDE-400004)
********
Users appear to be logged in when they are not because CDE dtterm sometimes
doesn't reset the utmp entry on exit.
FILE(s):
/usr/dt/bin/dtterm subset OSFCDEDT410
CHECKSUM: 33343 408
===============================================================================
This patch fixes two problems with the CDE window manager. In the first
problem, the CADDS5 (a third party cad tool) text window tends to walk
off the screen. In the second problem, the CDE icon box moves 29 pixels
higher along the x axis each time the user's home session is resumed.
PROBLEM: (CLD USG-04316) (Patch ID: OSF410CDE-400005)
********
Under the CDE window manager, the CADDS5 (a third party cad tool) Text Window
tends to walk off the screen.
PROBLEM: (QAR 49251) (Patch ID: OSF410CDE-400005)
********
The CDE icon box moves 29 pixels higher along the x axis each time the user's
home session is resumed.
FILE(s):
/usr/dt/bin/dtwm subset OSFCDEDT410
CHECKSUM: 03899 648
===============================================================================
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: (QARs 50057, 50155, 50353, SSRT0435U) (Patch ID: OSF410-400006)
********
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.
FILE(s):
/usr/share/sysman/bin/badpasswd subset OSFSYSMAN410
CHECKSUM: 15249 4 RCSfile: badpasswd RCS: 1.1.2.7
/usr/sbin/dop subset OSFSYSMAN410
CHECKSUM: 45868 40 RCSfile: dop.c RCS: 1.1.7.2
/usr/share/sysman/bin/doperror subset OSFSYSMAN410
CHECKSUM: 63161 5
/usr/share/sysman/bin/getpasswd subset OSFSYSMAN410
CHECKSUM: 12699 7 RCSfile: getpasswd RCS: 1.1.6.2
/usr/share/sysman/bin/getpriv subset OSFSYSMAN410
CHECKSUM: 12649 8 RCSfile: getpriv RCS: 1.1.2.4
===============================================================================
This patch fixes a LEX problem. Without this patch, LEX rejects quoted
regular expressions where the ending quote is preceded by a double backslash
backslash, as in: "\\"xxx, and produces the following message: "lex:(Warning
at line 8)Non-terminated string".
PROBLEM: (QAR 51280) (Patch ID: OSF410-400177)
********
LEX rejects a quoted regular expression where the ending quote is preceded
by a double backslash, as in: "\\"xxx. The following warning is produced by
LEX: "lex: (Warning at line 10)Non-terminated string". The resultant lex.yy.c
file may or may not compile cleanly.
To reproduce the problem, use the following lex specification:
%{
extern char cbuf[];
extern int clen;
%}
%%
"\\\"" {cbuf[clen++] = '"';}
"\\"n { cbuf[clen++]='\n'; }
"\\"t { cbuf[clen++]='\t'; }
"\\"b { cbuf[clen++]='\b'; }
"\\"r { cbuf[clen++]='\r'; }
"\\"f { cbuf[clen++]='\f'; }
"\\\\" { cbuf[clen++]='\\'; }
%%
char cbuf[100];
int clen;
int main()
{
clen = 0;
yylex();
cbuf[clen] = 0;
printf("%s\n", cbuf);
}
---------
sauron:test/qar/48948 [577%] lex yong.l
lex: (Warning at line 8)Non-terminated string
line 16: syntax error
lex: (Warning) bad state 205 175
sauron:test/qar/48948 [580%] lex yong.l
sauron:test/qar/48948 [599%] cc lex.yy.c -ll
sauron:test/qar/48948 [600%] a.out
abc
def
abcdef
FILE(s):
/usr/ccs/bin/lex subset OSFPGMR410
CHECKSUM: 00579 80
===============================================================================
uugetty - CD/DSR not dropping right away after dial-out.
PROBLEM: (QAR 49652) (Patch ID: OSF410-050)
********
When dialing out on a port running uugetty, an immediate hang-up is not
after the session completes. The hang-up occurs approximately 60 seconds
following the end of the session.
FILE(s):
/usr/lib/uucp/uugetty subset OSFUUCP410
CHECKSUM: 55446 224 RCSfile: uugetty.c RCS: 4.3.23.2
===============================================================================
This patch fixes a problem in which rwhod daemon can cause a core dump with a
segmentation fault.
PROBLEM: (HPAQC0XEH, TKTQ81868) (Patch ID: OSF410-400183)
********
This patch fixes a problem in which rwhod daemon can cause a core dump with a
segmentation fault.
A typical stack trace shows:
> 0 __getutid_r()[]
1 __getutid() []
FILE(s):
/usr/sbin/rwhod subset OSFCLINET410
CHECKSUM: 34638 24 RCSfile: rwhod.c RCS: 4.2.17.2
===============================================================================
SUPERSEDED PATCHES: OSF410-400149 (42.00)
This patch corrects the following:
- Fixes a DEC C compiler problem that occurred when compiling a structure tag
whose length exceeded 256 characters.
- This patch provides a new version of the DEC C compiler to fix QAR 49944.
It fixes a problem that causes the compiler to generate incorrect code for
switch statements whose expression is of type short or type char.
The version of this fixed compiler is "DEC C V5.2-035".
PROBLEM: (QAR 49944) (Patch ID: OSF410-400149)
********
This patch fixes a compiler problem where the DEC C compiler will generate
incorrect code for switch statements whose expression is of type short or
type char. The problem occurs at all optimization levels.
This problem can be identified by running the following test program.
% cat a.c
main()
{
short step = 1;
do {
switch (step++)
{
case 1 : printf("step = 1\n");
break;
case 2 : printf("step = 2\n");
break;
}
}
while (step <= 2);
}
# The incorrect program output is:
% cc a.c ; a.out
step = 1
# The correct program output is:
% cc a.c ; a.out
step = 1
step = 2
The version of this fixed compiler is "DEC C V5.2-035".
PROBLEM: (QAR 51448) (Patch ID: OSF410-400187)
********
This patch fixes a crash in the DEC C compiler that occurs when compiling
a structure whose tag is longer than 256 characters. The problem occurs only
when compiling with debug symbols (-g). Below is an example of a program that
will cause this crash.
% cat test.c
#define a(x) x##x##x##x##x##x##x##x##x##x##x##x##x##x##x##x
struct a(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX);
% cc -g test.c
cc: Fatal: A memory access violation (bus error or segmentation fault) has
occurred. Please submit a problem report.
FILE(s):
/usr/ccs/lib/cmplrs/cc/gemc_cc subset OSFCMPLRS410
CHECKSUM: 50994 4112
===============================================================================
This patch fixes a problem where the NTP deamon (xntpd) does not work using a
Spectracom radio clock as a reference.
PROBLEM: (HPXQ10VTZ/QAR 48622) (Patch ID: OSF410-400191)
********
This patch fixes a problem where the NTP deamon (xntpd) does not work using a
Spectracom radio clock as a reference. If NTP is configured for a radio clock,
at the first response from the clock, the code will loop using all CPU cycles.
FILE(s):
/usr/sbin/xntpd subset OSFCLINET410
CHECKSUM: 63921 304
===============================================================================
This patch corrects several serious problems with the "csh" command. Some of
these problems can cause the "grep" and "find" commands to fail, when the user
runs the commands under the "csh" shell.
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: (QARs 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, QAR 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.
FILE(s):
/usr/bin/csh subset OSFBASE410
CHECKSUM: 42040 248
===============================================================================
This patch fixes a problem in which the cron command deletes non-local file
system files mounted in either the /tmp, /var/tmp, or /var/preserve directories.
PROBLEM: (QAR 46084) (Patch ID: OSF410-400194)
********
This patch fixes a problem in which the cron command removes non-local file
system files mounted in either the /tmp, /var/tmp, or /var/preserve directories.
FILE(s):
/usr/var/spool/cron/crontabs/.new..root subset OSFBASE410
CHECKSUM: 19634 2
/usr/var/spool/cron/crontabs/.mrg..root subset OSFBASE410
CHECKSUM: 08670 5
===============================================================================
SUPERSEDED PATCHES: OSF410-400171 (56.00)
This patch corrects the following:
- Fixes the problem of t_optmgmt() T_NEGOTIATE calls returning T_SUCCESS,
but not actually negotiating the socket options. This behavior is a
UNIX95 specification standard compliance bug.
- Fixes a problem that manifests itself by the system hanging or becoming
inoperable when a number of XTI connections reaches 500.
PROBLEM: (QAR 49764) (Patch ID: OSF410-400171)
********
When attempting to establish a number of XTI connections, > 500, the client
system hangs and becomes inoperable. This fix will allow an application to
issue a large number of connect requests (up to 3K connections).
PROBLEM: (QAR 51684) (Patch ID: OSF410-400196)
********
This patch fixes the problem of t_optmgmt() T_NEGOTIATE calls returning
T_SUCCESS, but not actually negotiating the options.
FILE(s):
/sys/BINARY/xtiso.mod subset OSFBIN410
CHECKSUM: 22703 159
===============================================================================
SUPERSEDED PATCHES: OSF410-400115 (16.00)
This patch corrects the following:
- Under enhanced security, sometimes users (even root) are unable to log in
on graphics console, even after using dxdevices or edauth to clear the
t_failures count.
- On systems running enhanced security, user-written applications that call
auth_for_terminal() may fail with a segmentation fault.
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
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.
FILE(s):
/usr/ccs/lib/libsecurity.a subset OSFC2SEC410
CHECKSUM: 35199 396
/usr/shlib/libsecurity.so subset OSFBASE410
CHECKSUM: 22628 360
===============================================================================
This patch fixes several problems in the ex and vi editors.
o Blank lines in the .exrc file prevent the vi editor from executing.
o The ex editor does not properly manage the file name buffers
when a "write append" command fails.
o The vi editor may erroneously report a "Bad file number" error
message when switching between files.
PROBLEM: (UVO104615 QAR 44614 QAR 47303) (Patch ID: OSF410-400204)
********
Blank lines in the .exrc file prevent the vi editor from executing.
To recreate this problem, create a .exrc file in your home directory. Leave a
blank line at the end of the .exrc file. Enter the vi command; vi will exit
immediately and your terminal window will display the shell prompt.
PROBLEM: (QAR 39453) (Patch ID: OSF410-400204)
********
The ex editor does not properly manage the file name buffers when a "write
append" command fails.
For example, prior to invoking the ex editor, assume file "a" does not exist,
but file "b" does. Run ex without specifying a file name, enter some
characters and try to get ex to output these characters in append mode in
append mode to a file that does not exist. After it correctly reports
"no such file or directory", specify a file that does exist. For example:
systema> ex
:a
hello worlds
.
:w
No current filename
:w >> a
"aa" No such file or directory
:w >> b
"b" 3 lines, 12 characters
When you try to exit the file, ex will write to the wrong file.
:e b
No write since last change (:edit! overrides) #>-- won't do it
:xit #<-- Let's quit
"a" [New file] 3 lines, 12 characters #>-- ok, I'll write
for you
systema>
The problem is that ex creates a new file when it should not. After applying
this patch, the ex editor will provide the following error message:
No current file name
PROBLEM: (QAR 46284) (Patch ID: OSF410-400204)
********
The vi editor may erroneously report a "Bad file number" error message when
switching between files.
For example, if file "xx" has access privileges of -r--r--r--(no write enabled)
and file "yy" has privileges of -rw-r--r-- (write enabled), the following ort
example will cause vi to report "Bad file number":
vi xx yy
:n
Shift+Ctrl+^
dd
:w
Shift+Ctrl+^
:e!
"xx" [Read only] Bad file number
Shift+Ctrl+^
"yy" Bad file number
After applying this patch, the "xx" file is reported to be read-only and the
write will fail. The "yy" file, will be written with no error message.
error message.
FILE(s):
/usr/bin/ex subset OSFBASE410
CHECKSUM: 07506 288 RCSfile: ex.c RCS: 4.3.32.2
ex_temp.h Revision: 4.2.7.3
ex_addr.c Revision: 4.2.9.4
ex_re.h Revision: 4.2.7.3
ex_cmds.c Revision: 4.3.25.2
ex_temp.h Revision: 4.2.7.3
ex_cmds2.c Revision: 4.2.9.4
ex_temp.h Revision: 4.2.7.3
ex_cmdsub.c Revision: 4.2.19.3
ex_temp.h Revision: 4.2.7.3
ex_data.c Revision: 4.2.7.2
ex_extern.c Revision: 4.2.7.2
ex_re.h Revision: 4.2.7.3
ex_temp.h Revision: 4.2.7.3
ex_get.c Revision: 4.2.7.2
ex_io.c Revision: 4.4.34.2
ex_temp.h Revision: 4.2.7.3
ex_put.c Revision: 4.2.10.5
ex_re.c Revision: 4.2.9.7
ex_re.h Revision: 4.2.7.3
ex_set.c Revision: 4.2.7.3
ex_temp.h Revision: 4.2.7.3
ex_subr.c Revision: 4.3.9.4
ex_re.h Revision: 4.2.7.3
ex_temp.c Revision: 4.3.12.5
ex_temp.h Revision: 4.2.7.3
ex_tty.c Revision: 4.2.7.3
ex_unix.c Revision: 4.2.7.4
ex_temp.h Revision: 4.2.7.3
ex_v.c Revision: 4.2.7.3
ex_re.h Revision: 4.2.7.3
ex_vadj.c Revision: 4.2.7.2
ex_vget.c Revision: 4.2.14.4
ex_vmain.c Revision: 4.2.13.2
ex_voper.c Revision: 4.2.7.4
ex_vops.c Revision: 4.2.9.2
ex_vops2.c Revision: 4.2.11.2
ex_vops3.c Revision: 4.2.7.4
ex_vput.c Revision: 4.2.9.2
ex_vwind.c Revision: 4.2.7.2
ex_crypt.c Revision: 4.2.5.4
ex_temp.h Revision: 4.2.7.3
/usr/bin/edit
CHECKSUM: 07506 288
/usr/bin/vedit
CHECKSUM: 07506 288
/usr/bin/vi
CHECKSUM: 07506 288
/usr/bin/view
CHECKSUM: 07506 288
===============================================================================
This patch fixes a problem that causes dbx to hang when stepping past a
system() function call.
PROBLEM: (HPAQ20QW1, 51670) (Patch ID: OSF410-400205)
********
Attempting to step past a system() function call causes dbx to hang.
FILE(s):
/usr/ccs/lib/cmplrs/cc/dbx subset OSFBASE410
CHECKSUM: 39366 960 RCSfile: dbxsignal.c RCS: 1.1.16.5
===============================================================================
SUPERSEDED PATCHES: OSF410-046 (26.00)
This patch corrects the following:
- o Fixes a problem with the ikdebug debugger that causes a system to panic
with the following message:
panic: simple_lock: time limit exceeded
o Fixes a problem in which an AlphaStation 600, as well as other systems,
may crash when user mode debuggers are in use (for example, dbx or
ladebug).
- Reduces the kdebug memory usage.
- Fixes user mode breakpoints/single stepping.
- Fixes kdebug MP problems.
PROBLEM: (QAR 49695) (Patch ID: OSF410-046)
********
Kdebug uses too much memory reading in the kernel symbol table. The full
symbol table size can be > 7 MB. Use vmstat -P and look for kdebug line.
PROBLEM: (QAR 50184) (Patch ID: OSF410-046)
********
Kdebug sometimes confuses user mode breakpoints and/or single stepping for
requests to enter kdebug. If a kdebug prompt appears on the console
("db{0}> ") when either dbx or ladebug is being used for debugging. A hang
is also possible due to the following problem.
PROBLEM: ( 50184 ) (Patch ID: OSF410-046)
********
Kdebug entry may cause the system to hang. If kdebug is activated on an MP
machine, the system may hang with garbled messages printed on the console.
PROBLEM: (QAR 51380, QAR 51698, QAR 50184) (Patch ID: OSF410-053)
********
This patch fixes several debugger problems:
o This patch fixes a problem with the ikdebug debugger in which the
system panics with the following message:
panic: simple_lock: time limit exceeded
This problem can occur whenever any exception is encountered while
running the debugger.
o This patch fixes a problem in which an AlphaStation 600 as well as
other systems may crash when user mode debuggers are in use (for
example, dbx or ladebug).
This crash occurs because of a misplaced call to the console SAVETERM
and only happens if the console variable CONSOLE is set to GRAPHICS.
FILE(s):
/sys/BINARY/kdebug.mod subset OSFBIN410
CHECKSUM: 32393 234
===============================================================================
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: (CLD SSRT0438U) (Patch ID: OSF410CDE-400007)
********
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.
FILE(s):
/usr/dt/bin/dtpad subset OSFCDEDT410
CHECKSUM: 00003 112 RCSfile: dtpad.c RCS: 2.1.6.2
===============================================================================
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: (CLD SSRT0431U) (Patch ID: OSF410CDE-400008)
********
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.
FILE(s):
/usr/dt/bin/dtappgather subset OSFCDEDT410
CHECKSUM: 48360 56
/usr/dt/bin/dtlogin subset OSFCDEDT410
CHECKSUM: 38150 176
/usr/dt/config/Xsession.d/0030.dttmpdir subset OSFCDEDT410
CHECKSUM: 29822 5
===============================================================================
SUPERSEDED PATCHES: OSF410-047 (27.00)
This patch corrects the following:
- Fixes an automatic reboot problem when the system is booted from tape using
the custom_install.sh file in a mini-root enviroment.
- Fixes problems encountered when restoring file systems from a tape device
using the btextract utility.
PROBLEM: (QAR 50371) (Patch ID: OSF410-047)
********
This patch fixes the ADVANCED option to the btextract utility to correctly
restore /etc/fstab file entries. Without this patch, the following two errors
could occur:
o Entries in the /etc/fstab file will sometimes be incorrect after the
btextract utility completes.
For example in the following line, the entry for swap should actually be swap1:
/dev/rz1b swap ufs sw 0 2
o A restore operation deletes the entry for /dev/fd in the /etc/fstab file.
PROBLEM: (QAR 50873) (Patch ID: OSF410-047)
********
This patch fixes a problem encountered while using the btextract utility to
restore file systems. The utility displays a system tape table and asks you
which tape device you want to use to boot your system. If you choose a tape
device that does not contain a tape, the system displays the following error
messages:
Positioning the Tape.
Error on device named /dev/nrmt0h - Place tape drive unit ONLINE
Error: Tape drive is not accessible
PROBLEM: (QAR 51219) (Patch ID: OSF410-056)
********
This patch fixes the Bootable Tape utilities. An automatic reboot problem
when the system is booted from tape using the custom_install.sh file in a
mini-root enviroment was corrected.
To recreate this problem, create a custom_install.sh file in /usr/lib/sabt/sbin
directory with the following commands:
------------------------------------------------------------------
#!/sbin/sh
mount root_domain#root /mnt
#mount /dev/rz0a /mnt
/mnt/sbin/sysconfig -r bparm bootdef_dev="/dev/rrz1a"
/mnt/sbin/sysconfig -r bparm boot_dev="/dev/rrz1a"
/mnt/sbin/sysconfig -r bparm boot_osflags="A"
/mnt/sbin/reboot
------------------------------------------------------------------
where rz1 can be changed to the boot device where root resides. Where if root
device is rz0a and is ufs then uncomment the above line and comment the first
mount statement.
Create a bootable tape with selecting root filesystem to be backed up. After
booting from the tape, you will see that reboot hangs. You need to bring up
the system by hitting the power switch off/on.
After applying this patch, rewrite the custom_install.sh file as follows:
------------------------------------------------------------------
#!/sbin/sh
/sbin/sysconfig -r bparm bootdef_dev="/dev/rrz1a"
/sbin/sysconfig -r bparm boot_dev="/dev/rrz1a"
/sbin/sysconfig -r bparm boot_osflags="A"
/sbin/reboot
------------------------------------------------------------------
Create a bootable tape with selecting root filesystem to be backed up.
After booting from the tape, you will see that reboot does not hang.
FILE(s):
/usr/sys/bin/btextract subset OSFBINCOM410
CHECKSUM: 14079 71
/usr/sys/bin/mktape subset OSFBINCOM410
CHECKSUM: 50411 18
===============================================================================
SUPERSEDED PATCHES: OSF410-400118 (17.00), OSF410-400169 (54.00)
This patch corrects the following:
- Fixes a problem that occurs if the kernel tunable variable
"old-obreak" is set to zero and the system is running the Korn shell
(ksh). The shell gets caught in an infinite loop printing a message
similar to the following. Eventually the process will core dump.
/adp/bin/adpbkup[135]: no space
- Fixes a problem with the ksh shell program. ksh prevents a command which
runs in a sub-process from writing to a tape device.
- 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.
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.
FILE(s):
/usr/bin/ksh subset OSFBASE410
CHECKSUM: 39000 264
/usr/bin/posix/sh subset OSFBASE410
CHECKSUM: 39000 264
===============================================================================
Add support for DE500-BA 10/100 Ethernet adapter, and fix machine checks
encountered when using the KZPAM-CA or KZPAM-DA controllers.
PROBLEM: (Patch ID: OSF410-058)
********
Support for the DE500-BA requires recognition of a new PCI device ID and also
require specific code to operation the device.
FILE(s):
/usr/sys/data/if_tu_data.c subset OSFBINCOM410
CHECKSUM: 26001 8 RCSfile: if_tu_data.c RCS: 1.1.45.2
/usr/sys/include/io/dec/netif/if_tureg.h subset OSFBINCOM410
CHECKSUM: 61309 18
/etc/.new..sysconfigtab subset OSFBASE410
CHECKSUM: 10967 26
/etc/.mrg..sysconfigtab subset OSFBASE410
CHECKSUM: 39038 3
/sys/BINARY/tu.mod subset OSFHWBIN410
CHECKSUM: 42457 53
/usr/sys/data/pci_option_data.c
CHECKSUM: 52907 12 subset OSFBINCOM410
/usr/sys/include/io/dec/pci/pci.h
CHECKSUM: 22657 42 subset OSFBINCOM410
===============================================================================
SUPERSEDED PATCHES: OSF410-400211 (101.00)
This patch corrects the following:
- This patch fixes a problem in which the dd command can corrupt output on very
large files (2GB or greater) when the "conv=sparse" option is used.
PROBLEM: (QAR 47063) (Patch ID: OSF410-400211-1)
********
This patch fixes a problem in which the dd command can corrupt output on very
large files (2 GB or greater) when the "conv=sparse" option is used. In some
cases a seek error is reported:
dd seek error: Invalid argument
In other cases a corrupt file is created with no error reported.
FILE(s):
/sbin/dd subset OSFBASE410
CHECKSUM: 17308 32 RCSfile: dd.c RCS: 4.3.30.2
/usr/bin/dd subset OSFBASE410
CHECKSUM: 52732 32 RCSfile: dd.c RCS: 4.3.30.2
===============================================================================
This patch fixes the following problems in the DECwindows Session Manager
(dxsession) application. Ungraceful exit can be made through the window
manager's 'Close' button, whose behavior is inconsistent with that of
dxsession's 'End Session' button.
PROBLEM: (HPAQ210HY) (Patch ID: OSF410DX-400007)
********
Exiting from the DECwindows Session Manager (dxsession) via the 'Close' option,
of the window menu, results in an undesirable saving of the dxsession's scratch
file in /tmp. Use of this button also causes a behavior inconsistent with
dxsession's 'End Session' button.
FILE(s):
/usr/bin/X11/dxsession subset OSFOLDX11400
CHECKSUM: 44434 224
===============================================================================
This patch fixes a problem in which the rpc.rquotad daemon hangs when using
quotas for NFS filesystems in a TruCluster or Available Server (ASE) v1.4
environment.
PROBLEM: (MCPM21BM5) (Patch ID: OSF410-400214)
********
This patch fixes a problem in which the rpc.rquotad daemon hangs when using
quotas for NFS filesystems in a TruCluster or Available Server (ASE) v1.4
environment.
When attempting to get a report on user quotas for NFS mounted filesystems,
the quota command always return 'none'. The rpc.rquotad daemon on the NFS
server hangs until the connect system call eventually times out.
FILE(s):
/usr/sbin/rpc.rquotad subset OSFCLINET410
CHECKSUM: 65299 32 RCSfile: rpc.rquotad.c RCS: 1.1.12.2
===============================================================================
When setting the date with the clock_settime rtl service routine, the date
will not get past the date of 'Sat Sep 8 19:46:39 2001' If you try to set
past this date the routine returns a EINVAL error.
PROBLEM: (CLD MCPM20W7F, QAR 51771) (Patch ID: OSF410-400215)
********
When setting the date with the clock_settime rtl service routine, the date will
not get past the date of 'Sat Sep 8 19:46:39 2001'. If you try to set past
this date the routine returns a EINVAL error.
FILE(s):
/usr/ccs/lib/librt.a subset OSFLIBA410
CHECKSUM: 37152 59
/usr/shlib/librt.so subset OSFBASE410
CHECKSUM: 13142 72
===============================================================================
SUPERSEDED PATCHES: OSF410-400066 (9.00)
This patch corrects the following:
- DDR subsystem updated to handle SCSI devices returning a non-standard
device type.
- Fixes two problems with ddr_config. ddr_config previously would
sometimes build partial device records. ddr_config on Digital UNIX V4.0 was
not compatible with input files created prior to this version.
PROBLEM: (QAR 45730 and QAR 46647) (Patch ID: OSF410-400066)
********
DDR partially builds some device records.
This problem is extremely hard to detect, as the creation of device records
usually happens silently in the kernel as it encounters new devices. Symptoms
of this error may be slight oddities in device behavior. Unfortunately, the
extent to which behavior is affected cannot be predicted.
The problem can be seen most easily by executing the following :
Invoke "ddr_config -s disk DEC RZ28B".
The (failing) output should look as follows:
Building Device Information for:
Type = disk
Vendor ID: "DEC" Product ID: "RZ28B"
Applying Modifications from Device Record for:
Vendor ID: "DEC" Product ID: "RZ28"
TagQueueDepth = 0x4a
The (correct) output should look as follows:
Building Device Information for:
Type = disk
Vendor ID: "DEC" Product ID: "RZ28B"
Applying Modifications from Device Record for:
Vendor ID: "DEC" Product ID: "RZ28"
TagQueueDepth = 0x4a
Applying Modifications from Device Record for:
Vendor ID: "DEC" Product ID: "RZ28B"
TagQueueDepth = 0x40
PROBLEM: (QAR 45730 and QAR 46647) (Patch ID: OSF410-400066)
********
The "ddr_config -x" option fails to compile a cam_data.c file from a version
prior to Digital UNIX v4.0.
The following error messages will be reported:
ddr_config.ORIG: Line 3233: Syntax Error
ddr_config.ORIG: Line 3233: Failed parsing DENSITY_TBL entry
Conversion of /sys/data/cam_data.c failed.
Line numbers are relative to the temporary file /tmp/cam_data.tmp
Looking at the /tmp/cam_data.tmp file, the error occurs between two records
separated by a comma. For example:
TYPE
Record_A = { ....
}, <----- fails here
Record_B = { ...
};
PROBLEM: (HPAQB16E6) (Patch ID: OSF410-400218)
********
The DDR subsystem did not appropriately handle SCSI devices that return
non-standard device types. The standard device types range from 0 (disk
device) to 9 (Communications Device).
For example, a custom SCSI device that returns a device type of UNKNOWN (0x1f)
could panic the system with the following message:
"trap: invalid memory read access from kernel mode"
A device with a non-standard device type would ordinarily not be shown as
present on the system as it would require a custom SCSI device driver to
access it (one which does not come with the base operating system).
Note: Non-standard device types are supported by CAM in pre-v4.0 releases.
FILE(s):
/sbin/ddr_config subset OSFHWBASE410
CHECKSUM: 14256 256 RCSfile: ddr_config.c RCS: 1.1.7.2
/sys/BINARY/ddr.mod subset OSFBIN410
CHECKSUM: 07482 43
/etc/ddr.db subset OSFHWBASE410
CHECKSUM: 43407 15
/etc/.mrg..ddr.db subset OSFHWBASE410
CHECKSUM: 01589 3
===============================================================================
SUPERSEDED PATCHES: OSF410-400138 (34.00)
This patch corrects the following:
- Fixes problems in the error paths of the ATM subsystem. A majority of these
result in system crashes. These crashes are most prevalent when stressing
LAN Emulation (LANE).
- Fixes two panics in the lta driver, ATM LANE interoperability problems with
IBM switches, and slow recovery of UNI 3.0 signalling from network
interruptions.
PROBLEM: (CLD ZUO101032) (Patch ID: OSF410-400138)
********
This patch fixes a panic with the message "ltaintr: no TX pkt". An example
stack trace is shown below:
0 boot()
1 panic(s = 0xfffffc000065e1f0 = "ltaintr: no TX pkt")
2 ltaintr()
3 kn15aa_dispatch_iointr()
4 _XentInt()
5 swap_ipl()
6 boot()
7 panic(s = 0xfffffc000065e1f0 = "ltaintr: no TX pkt")
8 ltaintr()
9 kn15aa_dispatch_iointr()
10 _XentInt()
11 gh_zero_memory()
12 idle_thread()
The panic is a result of the ATM ILMI component overflowing a message buffer.
It will only occur for certain patterns of ATM addresses, and is most likely
to happen when ATM Classical IP is in use.
This patch may also fix other ILMI interoperability problems that do not
result in panics.
PROBLEM: (CLD ZUO101032) (Patch ID: OSF410-400138)
********
When the default UNI Version 3.0 signalling is used, it can sometimes take a
very long time (1.5 minutes or more) for ATM connections to be re-established
after a network interruption (e.g. a disconnected cable).
This patch changes the default recovery timer and greatly speeds up
re-connection following an interruption.
PROBLEM: (QAR 49699) (Patch ID: OSF410-400138)
********
This patch fixes a possible kernel memory fault panic that might occur on an
ATM ARP server. The panic might also occur if a remote system tries to
establish any ATM connection with invalid signalling parameters. The panic
occurs in the routine otto_manage_delvc().
PROBLEM: (Patch ID: OSF410-400138)
********
This patch fixes a possible interoperability problem with IBM 8260 switches
(certain firmware revisions). The problem prevents the Digital UNIX system
from joining an emulated LAN. The system repeatedly rejects of the
incoming point-to-multipoint VC connections with a cause value of 100.
This problem could also occur any time a remote system attempted a connection
where the Forward and Backward SDU sizes were not equal.
PROBLEM: (DEKBC1129) (Patch ID: OSF410-400219)
********
This problem is caused by corruption in an internal queue of the LANE ARP
code. The symptoms are either a system hang in process_event_queue() or
one of the following kernel memory fault stack traces:
0 boot()
1 panic("kernel memory fault")
2 trap()
3 _XentMM()
4 event_queue_insert()
5 la_arp_update()
0 boot()
1 panic("kernel memory fault")
2 trap()
3 _XentMM()
4 process_event_queue()
5 la_arp_refresh_callback()
6 timer_process()
PROBLEM: (TKTB26124) (Patch ID: OSF410-400219)
********
This problem is cause by incorrectly keeping track of the refernce counts of
the internal ATM ESI structures. The following is the stack trace of the kernel
panic:
0 boot()
1 panic("ATM ESI CLONE DELETE BOTCH")
2 atm_cmm_esi_cleanup()
3 atm_cmm_collector()
PROBLEM: (TKTB26122) (Patch ID: OSF410-400219)
********
The symptoms of this problem vary depending on whether or not patch 138.00
is installed. The problem is triggered by shutting down signaling (i.e.,
issuing the following command "atmsig down driver=xxxx") and then bringing
signaling back up (i.e., "atmsig up driver=xxxx") when LANE is active.
Without patch id 138.00 installed the following kernel memory fault will result:
0 boot
1 panic(s = 0xfffffc00006c7680 = "kernel memory fault")
2 trap()
3 _XentMM()
4 otto_manage_delvc()
5 otto_manage()
6 atm_cmm_zombiefy_vc()
7 atm_cmm_new_call()
8 AmUiAmtConInd()
9 amUsrM05S00()
10 amActvConTbl()
11 AmLiAsdDatInd()
12 AsUiAsdDatInd()
13 asV3xAa4Sx_y()
14 asV30ProcessSdPdu()
15 asV30Pdu8S4()
16 AsLiAalDatInd()
17 atm_sig_process_receive()
18 atm_sig_event_process()
With patch 138.00 installed, LANE will not restart unless the following
commands are issued:
"atmconfig down driver=xxxxx"
"atmconfig up driver=xxxxx"
PROBLEM: (TKTB25174) (Patch ID: OSF410-400219)
********
A system panic is caused by trying to funnel a thread which is in interrupt
context. The kernel stack trace associated with this problem is as follows:
0 boot()
1 panic("thread_block: interrupt level call")
2 thread_block()
3 unix_release_force()
4 unix_release()
5 cm_rcv()
6 atm_cmm_receive()
7 ottoread()
8 ltaintr()
9 intr_dispatch_post()
10 _XentInt()
FILE(s):
/sys/BINARY/atm.mod subset OSFATMBIN410
CHECKSUM: 42593 325
/sys/BINARY/atmip.mod subset OSFATMBIN410
CHECKSUM: 39233 241
/sys/BINARY/lane.mod subset OSFATMBIN410
CHECKSUM: 65378 348
/sys/BINARY/uni3x.mod subset OSFATMBIN410
CHECKSUM: 43862 935
/usr/sys/include/atm/sys/atm_smi.h subset OSFATMBINCOM410
CHECKSUM: 07815 7 RCSfile: atm_smi.h RCS: 1.1.9.3
/usr/sys/include/atm/cmm/cmm.h subset OSFATMBINCOM410
CHECKSUM: 39495 25 RCSfile: cmm.h RCS: 1.1.15.4
===============================================================================
This patch fixes a problem that can occur with programs linked with libaio.
These programs could dump core with a SIGSEGV signal or corrupt memory
when calling the close() function with a bad file descriptor value.
PROBLEM: (QAR50120, QAR40188, QAR47526, QAR47839) (Patch ID: OSF410-405063)
********
This patch fixes a problem that can occur with programs linked with libaio.
These programs could dump core with a SIGSEGV signal or corrupt memory when
calling the close() function with a bad file descriptor value.
A bad or incorrect file descriptor value would be one greater than or equal
to 4096 or less than 0.
The following is a sample stack trace:
thread 0xb signal IOT/Abort trap at >*[nxm_thread_kill, 0x3ff8053eab0]
0 nxm_thread_kill(...) [0x3ff8053eab0]
1 pthread_kill(...) [0x3ff8056ed4c]
2 (unknown)() [0x3ff805756ec]
3 __tis_raise(...) [0x3ff8010fb00]
4 raise(...) [0x3ff80159f40]
5 abort(...) [0x3ff80170a68]
6 errAbort(...) [0x3ff80565b04]
7 (unknown)() [0x3ff80566398]
8 (unknown)() [0x3ff807b220c]
9 (unknown)() [0x3ff807b3620]
10 exc_unwind(...) [0x3ff807b3664]
11 exc_raise_signal_exception(...) [0x3ff807b38e8]
12 (unknown)() [0x3ff81002490]
13 close(...) [0x3ff81003488]
14 main(argc = 4, argv = 0x11ffff988) ["aio_test.c":157, 0x120001d64]
FILE(s):
/usr/ccs/lib/libaio.a subset OSFLIBA410
CHECKSUM: 02889 20
===============================================================================
A potential security vulnerability in talkd has been corrected.
PROBLEM: (SSRT0446U) (Patch ID: OSF410-400223)
********
A potential security vulnerability has been discovered in talkd, where under
certain circumstances, system integrity may be compromised. Digital has
corrected this potential vulnerability.
FILE(s):
/usr/sbin/talkd subset OSFCLINET410
CHECKSUM: 25972 32 RCSfile: talkd.c RCS: 4.2.6.2
/usr/sbin/ntalkd
CHECKSUM: 25972 32
===============================================================================
This patch fixes the problem of the Environmental Monitoring daemon (envmond)
failing to start sometimes when the system boots up.
PROBLEM: (QAR: 51220) (Patch ID: OSF410DX-003)
********
This patch fixes the problem of the Environmental Monitoring daemon (envmond)
failing to start sometimes when the system boots up.
FILE(s):
/sbin/init.d/envmon subset OSFENVMON410
CHECKSUM: 51205 5 RCSfile: envmon RCS: 1.1.7.2
/usr/sbin/envmond subset OSFENVMON410
CHECKSUM: 38025 12
===============================================================================
This patch is an upgrade/replacement for the "FTA" FDDI driver and fixes a
DMA Error which can occur with the older driver. If it became necessary to
back out a partially constructed frame from the transmit queue, the older
driver was unable to properly backed out the frame before restarting. This
resulted in the following errors being logged to the /var/adm/messages file:
vmunix: fta0: Halted.
vmunix: fta0: Halt Reason: DMA Error
vmunix: fta0: Link Unavailable.
vmunix: fta0: Link Available.
PROBLEM: (749B23467/QAR 52293) (Patch ID: OSF410-400225)
********
This patch is an upgrade/replacement for the "FTA" FDDI driver and fixes a
DMA Error which can occur with the older driver. If it became necessary to
back out a partially constructed frame from the transmit queue, the older
driver was unable to properly backed out the frame before restarting. This
resulted in the following errors being logged to the /var/adm/messages file:
vmunix: fta0: Halted.
vmunix: fta0: Halt Reason: DMA Error
vmunix: fta0: Link Unavailable.
vmunix: fta0: Link Available.
FILE(s):
/sys/BINARY/fta.mod subset OSFHWBIN410
CHECKSUM: 51917 56
===============================================================================
SUPERSEDED PATCHES: OSF410DX-400005 (67.00)
This patch corrects the following:
- When creating a new user account with a home directory of root, the
permissions on the root directory are changed to 700, rendering the
root file system inaccessible to non-root users. Patch Kit-0001
causes a problem with the System V Environment (SVE)
/usr/opt/svr4/usr/bin/passwd command. If an invalid password is
entered, subsequent invocations of the passwd command,
/usr/bin/X11/dxaccounts command, or the account management commands
fail with the following error:
The password and group files are currently locked by another user.
- Fixes for miscellaneous problems with the account management commands,
specifically the Account Manager graphical user interface
(/usr/bin/X11/dxaccounts) and the command line interface (useradd, userdel,
groupadd, etc).
PROBLEM: (QAR 46281) (Patch ID: OSF410DX-400005)
********
Using the Modify Selected Users dialog box, if you changed a set of users
to be NIS Override users, then the icons for those users were updated to
reflect the change but the usernames in all the dialog box drop-down lists
were not updated. Specifically, the icons would be updated to have
the "+" or "-" indicator for the user but the user's name was not changed
to "user (+)" or "user (-)" in the drop-down lists.
The most noticeable symptom of this bug is a warning message printed to
stdout when double clicking on one of the modified users:
Warning: DtComboBoxWidget: Unable to find item to select
(DtComboBoxSelectItem).
PROBLEM: (QAR 48189) (Patch ID: OSF410DX-400005)
********
When running on an NIS master, using the Secondary Groups subdialog of the
Modify Selected NIS Users dialog box would not add the selected users to
NIS groups - only local groups. For example, if you selected user1 and
user2 and used the Secondary Groups dialog to add them as members of
group "users" and group "staff (NIS)", they would not be added as members
of "staff" in /var/yp/src/group.
PROBLEM: (QAR 48190) (Patch ID: OSF410DX-400005)
********
A related problem to 48189 above. If NIS is in use, then attempting to use
the Modify Selected Users dialogs to change the primary group for the
selected users would result in the error:
Group does not exists
When the primary group was a NIS group.
PROBLEM: (QAR 48191) (Patch ID: OSF410DX-400005)
********
If you attempt to change the primary group of a selected set of users using
ModifySelected dialog, the primary group of the users does not change.
However if you bring up the options dialog up by clicking the 'Options' button
and click Apply/Ok, the primary group all the selected users is changed.
PROBLEM: (QAR 50998) (Patch ID: OSF410DX-400005)
********
On an Enhanced Security (C2) system, when adding a new user, the password
field in /etc/passwd is empty instead of being set to an asterisk ("*").
This is not a security issue for login authentication but can be a security
issue for third party software that does not use Security Integration
Architecture (SIA) function calls. Such software ignores the protected
password database and uses only /etc/passwd for password checking.
PROBLEM: (QAR 49141) (Patch ID: OSF410DX-400005)
********
Dxaccounts would crash if you brought up a dialog from specific view,
changed to a different view and then OK'd that dialog. For example,
if you brought up the Create/Modify User dialog, chose View/Local Groups
to switch the main window to the Local Groups view, and then pressed
OK in the Create/Modify User dialog, dxaccounts would crash.
PROBLEM: (QAR 49386) (Patch ID: OSF410DX-400005)
********
While adding/modifying a user or group, the UID or GID entered was not being
validated against the user-defined minimums and maximums set in the
General Options dialog box.
PROBLEM: (QAR 39332) (Patch ID: OSF410DX-400005)
********
Running two conncurrent instances of the account management commands
is not supported. This restriction applies to the dxaccounts graphical user
interface and the useradd, usermod, userdel, groupadd, groupmod, and
groupdel commands. This restriction was release noted for Digital UNIX V4.0
and it is now enforced in the software.
In order to prevent concurrent access, each account management command
creates a lock file at startup called /etc/.AM_is_running. If any of
the commands are terminated abnormally (e.g. kill -9) then this lock file
will not be deleted and future command invocations will refuse to run
with the error message:
The password and group files are currently locked by another user.
Please try again later.
This message means that the account database files are either legitimately
locked OR one of the commands terminated abnormally leaving an
/etc/.AM_is_running lock file. If no other root users are using the account
management commands, simply delete the lock file.
PROBLEM: (QAR 47383) (Patch ID: OSF410DX-400005)
********
If NIS is not running on a system, then the Account Manager incorrectly
tries to access the NIS databases. This happens when the system
administrator uses the Modify Selected Users or Groups dialog boxes.
An error dialog box with an empty list is displayed that looked like:
Account Manager Error List:
---------------------------
Error accessing a system database file:
Please correct this error and restart Account Manager.
[OK]
PROBLEM: (QAR 48221) (Patch ID: OSF410DX-400005)
********
When running the Account Manager on an Enhanced Security (C2) system,
the "Remove User's Directory and Files" toggle button was ignored
when a single user is retired using the Retire dialog box. The users
directory would not be deleted. Only if multiple users were selected
would the toggle button be honored.
PROBLEM: (QAR 46468) (Patch ID: OSF410DX-400005)
********
When running the Account Manager on an Enhanced Security (C2) system,
immediately deleting a newly created template would cause a crash.
PROBLEM: (QAR 46730) (Patch ID: OSF410DX-400005)
********
When using useradd on an Enhanced Security (C2) system, the
administrative_lock_applied flag is set unconditionally.
Also, the usermod command ignored the administrative_lock_applied flag so the
account could not be unlocked without using the dxaccounts graphical user
interface or the edauth command.
Now useradd honors the default setting of the administrative_lock_applied
flag. Specifying the flag on the command line will override the default
setting. Note that defaults are set using the -D option to usermod.
Also, usermod now correctly honors the administrative_lock_applied flag.
PROBLEM: (QAR 44966) (Patch ID: OSF410DX-400005)
********
When using usermod on an Enhanced Security (C2) system, the -e and -f flags
were not honored. See the man page for a detailed description of these flags.
PROBLEM: (QAR 46916) (Patch ID: OSF410DX-400005)
********
Using usermod -G to add a user to several groups as in:
usermod user -G group1,group2,group3
would not add the user to all the specified groups.
PROBLEM: (Patch ID: OSF410DX-400005)
********
While printing the accounts defaults using 'usermod -D', the inactive-
interval (i.e the maximum number of days allowed between usage of a login
ID before that login ID is declared invalid) was incorrectly printed as
a date instead of an interval.
PROBLEM: (QAR 47123) (Patch ID: OSF410DX-400005)
********
Using "groupadd -g" to add a new group would crash and the group would not
get added if the directory /var/yp/src did not exist.
PROBLEM: (QAR 52127) (Patch ID: OSF410DX-400008)
********
When adding a new user using /usr/bin/X11/dxaccounts or /usr/sbin/useradd,
if the account is created with a home directory of "/" then the permissions
on / are changed to 700. This renders the root file system inaccessible
to non-root users. Note that the persmissions are changed despite
the error message that is displayed:
Errors encountered while adding the user: foo
Cannot create user's home directory
Home directory already exists
Initial files not copied to home directory
The new behavior is to not change the permissions on a new user's home directory
if that directory already exists.
PROBLEM: (QAR 52042) (Patch ID: OSF410DX-400008)
********
The previous patch kit, Patch Kit-0001, caused a problem with the System V
Environment (SVE) password command /usr/opt/svr4/usr/bin/passwd. If the user
enters an invalid password then subsequent invocations of the passwd command,
/usr/bin/X11/dxaccounts, or the account management commands would fail with
the following error:
The password and group files are currently locked by another user.
The problem was that the /etc/.AM_is_running lock file used by the account
managment commands was not being deleted properly.
FILE(s):
/usr/lib/nls/msg/en_US.ISO8859-1/accmgrcli.cat subset OSFSYSMAN410
CHECKSUM: 59334 3
/usr/bin/X11/dxaccounts subset OSFXSYSMAN410
CHECKSUM: 56048 456
/usr/lib/nls/msg/en_US.ISO8859-1/Dxaccounts.cat subset OSFSYSMAN410
CHECKSUM: 60178 8
/usr/sbin/groupadd subset OSFSYSMAN410
CHECKSUM: 56513 64
/usr/sbin/groupdel subset OSFSYSMAN410
CHECKSUM: 46478 64
/usr/sbin/groupmod subset OSFSYSMAN410
CHECKSUM: 55877 64
/usr/shlib/libaccmgr.so subset OSFSYSMAN410
CHECKSUM: 36918 312
/usr/sbin/useradd subset OSFSYSMAN410
CHECKSUM: 05231 72
/usr/sbin/userdel subset OSFSYSMAN410
CHECKSUM: 05778 64
/usr/sbin/usermod subset OSFSYSMAN410
CHECKSUM: 58986 72
===============================================================================
This patch fixes a problem with the cpio command in which cpio fails to create
multiple archives on 150 MB or 250 MB tape.
PROBLEM: (QAR 51798) (Patch ID: OSF410-065)
********
This patch fixes a problem with the cpio command in which cpio fails to create
multiple archives on 150 MB or 250 MB tape. The system displays the following
error message:
/dev/CTAPE1 weof 1 failed: I/O error
ERROR: Cpio operation failed.
FILE(s):
/sys/BINARY/cam_tape.mod subset OSFHWBIN410
CHECKSUM: 39740 198
===============================================================================
This patch corrects two problems that occur when using the dtksh command:
o dtksh can lose output lines when a pipe or I/O indirection is used.
o The following error message may be displayed after using a pipe in dtksh:
dtksh: hist_flush: EOF seek failed errno=9
PROBLEM: (EVT102013, QAR 50237, QAR 39301) (Patch ID: OSF410CDE-400009)
********
This patch fixes a problem in which the dtksh command can lose output lines
when a pipe or I/O indirection is used.
PROBLEM: (QAR 46945, QAR 32865) (Patch ID: OSF410CDE-400009)
********
This patch fixes a problem in which the following message may be displayed
after using a pipe in dtksh:
dtksh: hist_flush: EOF seek failed errno=9
FILE(s):
/usr/dt/bin/dtksh subset OSFCDEMIN400
CHECKSUM: 35279 848
===============================================================================
This patch fixes a problem in which the size field of a process displayed by
the acctcom command is displayed incorrectly.
PROBLEM: (TKTQ 72352) (Patch ID: OSF410-400230)
********
This patch fixes a problem in which the size field of a process displayed by
the acctcom command is displayed incorrectly. Typically, processes that use
a lot of memory will display very invalid size values. These sizes will either
be absurdly large or negative. Compile and run the following program. Acctcom
Acctcom will display a size that is about 8 times larger than the actual memory
memory usage.
#include
#include
#include
#include
#include
#define ALLOC_SIZE 1024 * 1024 /* 1M byte */
main()
{
int i;
struct rusage ru;
i = fork();
if (i == 0) {
child();
}
else {
wait3(NULL,0,&ru);
printf("size information %ld %ld %ld\n",ru.ru_ixrss,ru.ru_idrss,
ru.ru_isrss);
}
}
child()
{
int counter;
int i;
char *address;
for( counter = 1 ; counter < 100 ; counter++ ) {
address = ( char * )malloc( sizeof( char ) * ALLOC_SIZE );
if( address == NULL ) {
printf( "Can't allocate memory.\n" );
sleep( 60 );
exit( 0 );
}
for( i = 0 ; i < ALLOC_SIZE ; i++ ) {
*address = ( char )( counter % 255 );
address ++;
}
printf( "Allocate %5dM byte\n" , counter );
}
exit( 1 );
}
FILE(s):
/usr/bin/acctcom subset OSFACCT410
CHECKSUM: 62535 40 RCSfile: acctcom.c RCS: 4.3.21.2
===============================================================================
SUPERSEDED PATCHES: OSF410-031 (1.00), OSF410-400105 (69.00),
OSF410-400148 (41.00), OSF410-400125 (21.00),
OSF410-400176 (70.00), OSF410-400176-1 (70.01),
OSF410-400217 (110.00), OSF410-400228 (126.00),
OSF410-400239B (160.00), OSF410-400231 (128.00)
This patch corrects the following problems:
- Fixes two problems that occur on AdvFS systems:
o An AdvFS data corruption problem can occur in user files.
This problem will not produce either a core file or return non-zero system
codes when accessing the corrupted file.
o The verify command does not detect corrupted files.
- 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.
- Fixes a problem with AdvFS in which the following two panics occur:
AdvFS Exception Module = 1, line = 1891
kernel memory fault
- Systems running with AdvFS and LSM under heavy I/O loads can have sluggish
interactive performance. In a DECsafe environment, these systems can
encounter unexpected relocation of services.
- Idle time is reset on broadcast message when AdvFS is the root file system.
- Fixes an AdvFS hang that could occur while running vdump.
- Fixes a problem where AdvFS hangs in routine cleanup_closed_list.
- Fixes a system panic with the message "simple_lock: time limit exceeded".
- Fixes an "ADVFS EXCEPTION, Module = 26" panic that occurs after an "advfs
I/O error" console message.
PROBLEM: (ZPOB82799) (Patch ID: OSF410-031)
********
This fixes a problem where a hang occurs on an AdvFS filesystem.
This problem occurs when a thread is looping in routine "cleanup_closed_list".
Sample stack after forced crash:
stop_secondary_cpu()
panic("cpu_ip_intr: panic request")
cpu_ip_intr()
_XentInt()
cleanup_closed_list()
fs_cleanup_thread()
PROBLEM: (GOZ100505) (Patch ID: OSF410-400105)
********
A system will panic with the panic string "simple_lock: time limit
exceeded".
The stack trace of the panicing process is as follows:
panic("simple_lock: time limit exceeded")
simple_lock_fault()
simple_lock_time_violation()
msfs_getpage()
u_seg_fault()
u_map_fault()
vm_fault()
trap()
_XentMM()
PROBLEM: (QAR 50227) (Patch ID: OSF410-400148)
********
This patch fixes an "ADVFS EXCEPTION" panic after an "advfs I/O error" message
to the console. The traceback of the panic thread will be as follows:
panic()
advfs_sad()
ftx_fail_2()
ftx_fail()
fs_write()
msfs_write()
vn_write()
rwuio()
write()
syscall()
_Xsyscall().
PROBLEM: (HPAQ92E5E) (Patch ID: OSF410-400125)
********
The system is hung while running vdump and there is a thread with the followijg
signature (note: this is _NOT_ the vdump thread):
0 imm_get_next_xtnt_desc() [../../../../src/kernel/msfs/bs/bs_inmem_map.c]
1 imm_merge_xtnt_map() [../../../../src/kernel/msfs/bs/bs_inmem_map.c]
PROBLEM: (HPXQ42587, QAR46237) (Patch ID: OSF410-400176)
********
On an AdvFS system, a broadcast message will cause the idle time to be reset to
zero.
(Patch ID: OSF400-176-1)
PROBLEM: (QAR 36779) (Patch ID: OSF410-405054 reference information)
********
This patch fixes a problem that occurs when running the NetWorker
Version 4.2c application. The NetWorker application is unable to
reset the atime (access time) attribute on files being accessed. No
errors or warnings are displayed.
Without this patch, NetWorker Version 4.2c will not perform well.
PROBLEM: (TKTR71564 QAR 36411) (Patch ID: OSF410-400217)
********
Systems running with AdvFS and LSM under heavy I/O loads can have sluggish
interactive performance. In a DECsafe environment, these systems can
encounter unexpected relocation of services.
PROBLEM: (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF410-400217)
********
A system can hang after the message "syncing disks..." prints during a panic.
When a hang occurs, the "syncing disks..." message does not print entirely
and the system does not take a dump.
A time-out mechanism was added to the "syncing disks" logic. This mechanism
improves the reliability of getting a dump by using the system clock to break
out of the "syncing disks" path and take a dump if no progress is being made
on reducing the number of buffers to be flushed. The numbers printed
periodically between the "syncing disks..." and "done" messages are the number
of buffers left to flush.
PROBLEM: (MGO102584) (Patch ID: OSF410-400228)
********
This patch fixes AdvFS to prevent the following two panics:
AdvFS Exception Module = 1, line = 1891
kernel memory fault with the following stack trace:
_XentMM()
bs_refpg_int()
bs_refpg()
tagdir_get_info()
bs_bfdmn_activate()
bs_bfdmn_tbl_activate()
fs_fset_get_info()
msfs_real_syscall()
msfs_syscall()
syscall()
_Xsyscall()
PROBLEM: (QAR 45580) (Patch ID: OSF410-400239B)
********
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.
Due to the pthreads fix vdump and vrestore need to be redistributed.
PROBLEM: (QAR 51304, QAR 51596) (Patch ID: OSF410-400231-1)
********
This patch fixes two problems that occur on AdvFS systems:
An AdvFS data corruption problem can occur in user files. This problem occurs
when AdvFS stores two different versions of a particular page (an 8K segment).
This problem will not produce either a core file or a return non-zero system
codes when accessing the corrupted file. The verify command will not detect
the corrupted file.
This patch provides the following:
1. The OS is corrected to prevent any new files from being corrupted.
2. The verify program now recognizes data corruptions.
3. The verify -f command detects the corruption and moves the file into a
temporary file. Another temporary file is created to show the contents
of the corresponding "visible" page. These files are then available for
analysis by the user for the purpose of manually repairing the corruption.
The following is an example of a recovery procedure.
To detect a corrupted file:
Run the verify utility, which resides in /sbin/advfs.
# verify test_domain
+++ Domain verification +++
Domain Id 32d3e638.000a46a0
Checking disks ...
Checking storage allocated on disk /dev/rz1a
Checking mcell list ...
Checking mcell position field ...
Checking tag directories ...
+++ Fileset verification +++
+++ Fileset test_fileset +++
Checking frag file headers ...
Checking frag file type lists ...
Scanning directories and files ...
Overlapping frag data corruption detected in:
File: /50226.file.4
Page: 1
Run verify -f on this domain to enable recovery of this data.
Scanning tags ...
Searching for lost files ...
#
The verify utility has detected a corrupted file in fileset test_fileset. The
name of the file is "50226.file.4" and it is located in the highest directory
of the fileset when it is mounted. The page that is corrupted is page 1.
Verify also suggests running verify again using the -f flag to enable recovery
of the hidden data for page 1.
At this point there are two choices:
1. Delete the file and recreate it. The corruption problem has been fixed
on the system. The newly created file will not exhibit the undesired
behavior.
2. Run verify with the -f flag to identify the corrupted data.
To identify the corrupted data:
Run the verify command with the -f flag.
# verify -f test_domain
+++ Domain verification +++
Domain Id 32d3e638.000a46a0
Checking disks ...
Checking storage allocated on disk /dev/rz1a
Checking mcell list ...
Checking mcell position field ...
Checking tag directories ...
+++ Fileset verification +++
+++ Fileset test_fileset +++
Checking frag file headers ...
Checking frag file type lists ...
Scanning directories and files ...
Overlapping frag data corruption detected in:
File: /50226.file.4
Page: 1
Temporary files created representing the two versions of page 1 of file
/50226.file.4
Refer to the README file accompanying the patch for a description of how
to use these temporary files to recover from this overlapping frag
corruption problem. Scanning tags ...
Searching for lost files ...
#
The verify utility reports that it has created two temporary files in the
same directory as the corrupted file. Mount the fileset to indentify these
two files:
# mount test_domain#test_fileset /test
# ls -l /test
total 169
drwx------ 2 root system 8192 Jan 8 13:23 .tags
-rw-r--r-- 1 root system 24576 Jan 9 12:27 50226.file.1
-rw-r--r-- 1 root system 40960 Jan 9 12:27 50226.file.2
-rw-r--r-- 1 root system 32768 Jan 9 12:27 50226.file.3
-rw-r--r-- 1 root system 24576 Jan 9 12:27 50226.file.4
-rw------- 1 root system 8192 Jan 13 14:32 50226.file.4.page_1.ext
-rw------- 1 root system 8192 Jan 13 14:32 50226.file.4.page_1.frag
-rw-r----- 1 root operator 8192 Jan 8 13:23 quota.group
-rw-r----- 1 root operator 8192 Jan 8 13:23 quota.user
The .ext and .frag files contain information from the corrupted area. In the
example above:
50226.file.4 The original corrupted file
50226.file.4.page_1.ext A file containing the hidden version of page 1
of the corrupted file. A read() cannot
retrieve this data.
50226.file.4.page_1.frag A file containing the frag version of page 1
of the corrupted file. This is the same data
that a read() of page 1 would return.
To fix the corrupted file:
A
1. View the .ext and .frag files to determine which to keep. Note that what
might really be desired is a merge of the two.
If the file 50226.file.4.page_1.ext contains the desired data, enter:
# ln -s 50226.file.4.page_1.ext desired_page_1
If the file 50226.file.4.page_1.frag contains the desired data, enter:
# ln -s 50226.file.4.page_1.frag desired_page_1
If a merge of the two must be done, do the merge and put the result
into a new file called desired_page_1.
2. Create a new fixed version of the corrupted file using the corrupted file
and new file (desired_page_1 in this example).
A. Copy page 0 (good page) from the corrupted file into a new file:
# dd if=50226.file.4 of=newfile bs=8192 count=1
B. Append the desired page 1 to the new file by seeking over 1 page in
the output file before writing:
# dd if=desired_page_1 of=newfile bs=8192 count=1 seek=1
C. Append the remainder of the original file to the end of the new file
by skipping past the first two pages of the input file before reading,
and seeking past the first 2 pages (already rewritten) in the output
file before writing:
# dd if=50226.file.4 of=newfile bs=8192 seek=2 skip=2
Run the diff command on the new and the original file to confirm that
only page 1 has changed to and that the difference is what is desired.
For example:
diff newfile 50226.file.4
D. Rename the new file and remove the temporary files:
# mv newfile 50226.file.4
# rm 50226.file.4.page_1.ext 50226.file.4.page_1.frag desired_page_1
If desired, the verify command can now be run on the domain again to
confirm that the data corruption problem is gone.
FILE(s):
/sys/BINARY/advfs.mod subset OSFADVFSBIN410
CHECKSUM: 27647 1131
/sbin/advfs/logread subset OSFADVFS410
CHECKSUM: 28446 32 RCSfile: logread.c RCS: 1.1.2.3
/sbin/advfs/verify subset OSFADVFS410
CHECKSUM: 00307 224 RCSfile: verify.c RCS: 1.1.15.2
/usr/lib/nls/msg/en_US.ISO8859-1/verify.cat subset OSFADVFS410
CHECKSUM: 53996 12
/sbin/vdump subset OSFADVFS410
CHECKSUM: 30119 432
/sbin/vrestore subset OSFADVFS410
CHECKSUM: 36356 464
===============================================================================
SUPERSEDED PATCHES: OSF410X11-400013 (104.00)
This patch corrects the following:
- On systems with PowerStorm 4D40T, 4D50T, or 4D60T graphics options, on X
server may hang every 49 days.
- Screen flickers on and off when in power-save mode.
PROBLEM: (QAR 50045) (Patch ID: OSF410X11-400013)
********
On a system with a graphics card and monitor which support VESA Display Power
Management Signalling (DPMS), the monitor can become stuck in power-save mode
or the screen can flicker on and off when the X server screen saver is turned
off, DPMS is enabled, and the mouse is moved to bring the display out of power-
save mode. The display does not come out of power-save mode correctly until
you press a key on the keyboard or click a mouse button.
This problem is particularly noticeable on ALPHAbook 1 systems.
PROBLEM: (7KSB31809) (Patch ID: OSF410X11-400014)
********
On systems with PowerStorm 4D40T, 4D50T, or 4D60T graphics options, the X
server may hang (and not exit) at or near the following local times:
Fri Jan 31 03:14:51 1997
Fri Mar 21 20:17:39 1997
Sat May 10 14:20:26 1997
Sun Jun 29 07:23:13 1997
Mon Aug 18 00:26:01 1997
Mon Oct 6 17:28:48 1997
Tue Nov 25 09:31:35 1997
FILE(s):
/usr/shlib/X11/libos.so subset OSFX11410
CHECKSUM: 22610 272
===============================================================================
This patch fixes the following problem in the Motif toolkit. The drag-n-drop
operation fails, which may cause Motif applications to abort.
PROBLEM: (USG-00572 and QAR 51941) (Patch ID: OSF410X11-400015)
********
Motif applications may abort when you use the drag-and-drop feature. Motif
toolkit function XmCreateDragIcon() gets a "BadMatch (invalid parameter
attributes)" error and then crashes because the code fails to set the correct
image dimensions.
FILE(s):
/usr/lib/libXm.a subset OSFX11410
CHECKSUM: 45038 2357
/usr/shlib/libXm.so subset OSFX11410
CHECKSUM: 63442 2224
===============================================================================
SUPERSEDED PATCHES: OSF410-405023 (6.00), OSF410-400146 (39.00)
This patch corrects the following:
- Fixes "kernel memory fault" panics from the kernel malloc() routine
when System V FIFOs created via STREAMS and fattach() are in use.
- Fixes a problem that causes the system to panic with a kernel memory fault
or "malloc_audit: guard space corruption" with osr_run as an entry in the
stack.
- Prevents delivery of data in subsequent streams messages with one read of a
streams pipe. This problem only happens if the read has a message length
greater than the length of the first message in the pipe.
PROBLEM: (QAR 48449) (Patch ID: OSF410-405023)
********
When reading a streams pipe, if more than one message is in the pipe, a read
with a message length greater than the first message will result in reading
all of the messages in the pipe concatenated.
PROBLEM: (QARs 49942 & 49814) (Patch ID: OSF410-400146)
********
This patch fixes a problem that causes the system to panic with a kernel memory
fault or "malloc_audit: guard space corruption" with osr_run as an entry in
the stack.
At this time no additional stack information is available.
PROBLEM: (QAR 52041) (Patch ID: OSF410-400236)
********
A "kernel memory fault" panic will be seen originating from the malloc()
routine. The top stack entries will be as follows. Many different kernel
routines may appear in the stack below malloc().
panic("kernel memory fault")
trap()
_XentMM()
malloc()
This problem is due to malloc() bucket corruption that occurs when there is a
racing close() and fdetach() of a System V fifo. In the dump the thread that
did the racing close can often be found with the traceback:
thread_block()
vfs_busy()
dounmount()
sth_update_times()
osr_close_subr()
pse_close()
speclose()
spec_close()
vn_close()
closef()
close()
syscall()
_Xsyscall()
FILE(s):
/sys/BINARY/streams.mod subset OSFBIN410
CHECKSUM: 05433 268
===============================================================================
SUPERSEDED PATCHES: OSF410-400080 (11.00), OSF410-400106 (15.00),
OSF410-400119 (18.00), OSF410-400133 (32.00),
OSF410-400139 (35.00), OSF410-400143 (37.00),
OSF410-400153 (46.00), OSF410-400154 (47.00),
OSF410-400154-1 (47.01), OSF410-400189 (80.00),
OSF410-400210 (96.00), OSF410-400131 (24.00),
OSF410-400195 (84.00), OSF410-400226 (123.00),
OSF410-400227 (125.00), OSF410-400227-1 (125.01),
OSF410-400241 (138.00), OSF410-400239 (136.00)
This patch corrects the following:
- Fixes a problem in which multi-threaded applications that reference
a pthread_mutex_destroy routine may fail with EBUSY or the application
may hang.
- Fixes a problem with the DECthreads "legacy" library. Specifically,
this patch addresses the potential hang of programs that us the Draft 4
interface for pthread_once().
- Fixes a problem whereby mkpasswd fails for /etc/passwd files that
are very large (containing roughly 30 thousand to 80 thousand entries).
- Fixes problems in threaded applications with incorrect signal behavior
and thread creation failures using user allocated stacks.
- Fixes threaded applications seeing a deadlock with fork(), premature
stack overflows, corrupted mutexes, and orphaned condition variable
or mutex blocking structures.
- Fixes problems in threaded programs related to DECthreads bugchecks,
fork(), stack corruptions and exception handling problems. This patch
may also fix problems with non-threaded programs relating exception
handling.
- Fixes problems that might cause threaded programs running under Digial
UNIX 4.0 to hang. Specifically, this patch addresses situations related
to DECthread bugcheck, pthread_once() or cma_once(), and unhandled
exceptions.
- 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.
- Fixes a problem in which mallopt(M_MXFAST), instead of making malloc()
faster, makes it as much as 65 times slower.
- Fixes a problem where a call to popen() hangs after a bad call to pclose()
in a threaded program.
- 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.
- Fixes a problem that may cause older call_shared FORTRAN applications to
find missing symbols in libc.so.
- Fixes a deadlock problem that may occur with multi-threaded applications
calling any of the functions for getting system database information
(gethostent, getservent, etc.) and which also call fork. The deadlock may
occur when such applications are run on systems configured to use YP services.
- Fixes a problem that occurs after a user logs into a system with an
SRV4-style LAT device. When the ttyslot function is called, the system
fails to find the device and returns a value of zero, indicating an error
in the ttyslot function.
- Fixes a problem that prevents gethostent() from returning all YP or bind
served entries.
- Fixes a problem in which the interaction of signals with setjmp/longjmp
called repeatedly in a loop was causing a segmentation violation and core
dump in a customer's application.
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
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 multi-threaded 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: 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: (CLD 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: (QARs 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: (CLD 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's 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: (IPMT 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 multi-thread
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 multi-threaded applications.
PROBLEM: (IPMT HPAQ309UJ) (Patch ID: OSF410-400226)
********
This patch corrects problems encountered where multi-threaded 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 multi-threaded 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 taht the signal
is pending against a thread, the thread will NOT have the signal blocked,
but it will not be delivered to that thread.
FILE(s):
/usr/sbin/auditd subset OSFBASE410
CHECKSUM: 53860 504 RCSfile: auditd.c RCS: 1.1.8.6
/usr/ccs/lib/libc.a subset OSFCMPLRS410
CHECKSUM: 54904 1954
/usr/ccs/lib/libc_r.a subset OSFCMPLRS410
CHECKSUM: 54904 1954
/shlib/libc.so subset OSFBASE410
CHECKSUM: 42565 1543
/shlib/libc_r.so subset OSFBASE410
CHECKSUM: 42565 1543
/usr/lib/nls/msg/en_US.ISO8859-1/libc.cat subset OSFBASE410
CHECKSUM: 05560 13
/usr/shlib/libexc.so subset OSFBASE410
CHECKSUM: 55605 48
/usr/shlib/libpthread.so subset OSFBASE410
CHECKSUM: 18257 416
/usr/shlib/libpthreads.so subset OSFBASE410
CHECKSUM: 63758 120
/usr/shlib/libpthreaddebug.so subset OSFBASE410
CHECKSUM: 65354 144
/sbin/ls subset OSFBASE410
CHECKSUM: 00941 416 RCSfile: ls.c RCS: 4.3.23.6
RCSfile: flsbuf.c RCS: 4.2.15.2
RCSfile: errlst.c RCS: 4.2.9.2
RCSfile: __lc_dlsym.c RCS: 1.1.2.5
RCSfile: sia_globals.c RCS: 1.1.11.2
RCSfile: dlsym.c RCS: 1.1.2.5
/usr/sbin/mkpasswd subset OSFBASE410
CHECKSUM: 61247 24 RCSfile: mkpasswd.c RCS: 4.2.32.2
/usr/include/ndbm.h subset OSFINCLUDE410
CHECKSUM: 22279 6 RCSfile: ndbm.h RCS: 4.2.24.2
/usr/lib/nls/msg/en_US.ISO8859-1/nslookup.cat subset OSFCLINET410
CHECKSUM: 10924 7
/usr/bin/nslookup subset OSFCLINET410
CHECKSUM: 12200 96
/sbin/mount subset OSFBASE410
CHECKSUM: 48352 512 RCSfile: mountxdr.c RCS: 4.2.7.2
RCSfile: mountxdr_v3.c RCS: 1.1.2.3
RCSfile: mount.c RCS: 4.3.59.2
RCSfile: mountxcdr.c RCS: 1.1.2.4
/sbin/umount subset OSFBASE410
CHECKSUM: 43246 336 RCSfile: umount.c RCS: 4.2.18.2
/usr/sbin/ypbind subset OSFCLINET410
CHECKSUM: 56324 328 RCSfile: ypbind.c RCS: 4.2.7.3
/usr/include/netdb.h subset OSFINCLUDE410
CHECKSUM: 11906 9 RCSfile: netdb.h RCS: 4.2.28.3
/usr/include/arpa/nameser.h subset OSFINCLUDE410
CHECKSUM: 10429 12 RCSfile: nameser.h RCS: 4.2.17.2
/usr/include/pthread.h subset OSFINCLUDE410
CHECKSUM: 58953 66 RCSfile: pthread.h RCS: 1.1.13.6
/usr/include/resolv.h subset OSFINCLUDE410
CHECKSUM: 19041 11 RCSfile: resolv.h RCS: 4.2.20.2
/usr/include/tis.h subset OSFINCLUDE410
CHECKSUM: 53110 16 RCSfile: tis.h RCS: 1.1.9.2
===============================================================================
This patch fixes a problem in which loadable kernel modules that are loaded
with the kloadsrv daemon at run time, may cause a system panic.
PROBLEM: (QAR 51743) (Patch ID: OSF410-400243)
********
This patch fixes a problem in which loadable kernel modules that are loaded
with the kloadsrv daemon at run time, may cause a system panic. Generally,
this problem will only be seen by engineers who are developing loadable
drivers.
This problem will only be seen in loadable drivers that are compiled with
the "cc -Wb,-static ..." switch and have a reference to the gp register in
the first instruction. The dis command can be used to determine if the gp
register is referenced in the first instruction.
FILE(s):
/sbin/kloadsrv subset OSFBASE410
CHECKSUM: 32351 176 RCSfile: kloadsrv.c RCS: 4.2.15.6
===============================================================================
This patch fixes several problems with the network lock daemon, rpc.lockd:
o NFS mounted file systems may hang.
o An error occurs with NFS mounted user mail files. This error prevents
the files from being locked and prints out the following message:
cannot lockf
o An NFS problem may occur. The system displays the following error message:
NFS error 48 cannot bind sockets
PROBLEM: (QAR 51227) (Patch ID: OSF410-400246)
********
This patch fixes a problem that can cause an NFS mounted file sytem to hang.
The problem is caused by an incorrect FCNTL return.
PROBLEM: (QAR 14680) (Patch ID: OSF410-400246)
********
This patch fixes a problem that can cause the rpc.lockd program to fail because
it loses a message granting NLM approval. The message would be:
call unlock_res stat granted
rather than:
call lock_res stat blocked
PROBLEM: (QAR 43271) (Patch ID: OSF410-400246)
********
This patch fixes a problem that can cause an NFS mounted file system to hang.
The problem is caused by an incorrect FCNTL return.
PROBLEM: (QAR 45844) (Patch ID: OSF410-400246)
********
This patch fixes a problem that can cause an NFS mounted file system to hang
during file locking.
PROBLEM: (QAR 46298) (Patch ID: OSF410-400246)
********
This patch fixes a problem that can cause rpc.lockd to crash with a core dump.
Multi-vendor environments are particularly susceptible to this problem.
PROBLEM: (QAR 46630) (Patch ID: OSF410-400246)
********
This patch fixes a problem that occurs with NFS mounted user mail files.
The error prevents the files from being locked and prints out the following
message:
cannot lockf
PROBLEM: (QAR 49265) (Patch ID: OSF410-400246)
********
This patch fixes an NFS problem. The system displays the following error
message:
NFS error 48 cannot bind sockets
Other fixes include the cleanup of some error messages and to direct more
errors to syslog.
Additionally, the signal handler (SIGALRM) was redesigned to improve the
efficiency of retranmission and to prevent possible lost transmits.
FILE(s):
/usr/sbin/rpc.lockd subset OSFNFS410
CHECKSUM: 12114 136
===============================================================================
Infrequently, under heavy disk I/O loads, user data can be written to the
wrong disk, resulting in data corruption.
PROBLEM: (QAR 49540) (Patch ID: OSF410-405065)
********
Infrequently, under heavy disk I/O loads, user data can be written to the
wrong disk, resulting in data corruption.
FILE(s):
/sys/BINARY/cam_simport.mod subset OSFHWBIN410
CHECKSUM: 63519 238
===============================================================================
Boot capability for new hardware support requires a new genvmunix. This
patch delivers an updated genvmunix for that purpose.
PROBLEM: (Patch ID: OSF410-058B)
********
Boot capability for new hardware support requires a new genvmunix. This
patch delivers an updated genvmunix for that purpose.
FILE(s):
/genvmunix subset OSFHWBASE410
CHECKSUM: 51473 7973
===============================================================================
SUPERSEDED PATCHES: OSF410-039 (5.00), OSF410-034 (2.00),
OSF410-400100 (14.00), OSF410-405037 (7.00),
OSF410-405036 (64.00), OSF410-400141 (36.00),
OSF410-400165 (50.00), OSF410-052 (76.00),
OSF410-059 (100.00), OSF410-405054 (71.00),
OSF410-400127 (22.00), OSF410-400197 (86.00),
OSF410-062 (113.00), OSF410-063 (119.00),
OSF410-400216 (109.00), OSF410-400208 (95.00),
OSF410-405044 (61.00), OSF410-049 (75.00),
OSF410-405053 (103.00), OSF410-405059 (105.00),
OSF410-400186 (78.00), OSF410-400201 (87.00),
OSF410-405045 (62.00), OSF410-400198 (114.00),
OSF410-400232 (129.00), OSF410-400233 (130.00),
OSF410-400242 (139.00), OSF410-400250 (144.00),
OSF410-405062 (106.00), OSF410-068 (133.00),
OSF410-400235 (134.00), OSF410-400221 (116.00),
OSF410-405068 (148.00), OSF410-405058 (157.00)
This patch corrects the following problems:
- This patch provides support for the fuser utility. This utility displays a
list of processes that are holding references to a file on the file system
that cannot be unmounted.
- This patch does the following:
o Fixes an isp1020 SCSI driver performance regression.
o Provides HSZ70 support.
- Fixes a problem in which the ufs property list can become corrupted.
- Fixes a problem with the fsck command. When fsck is run on a non-existent
file system or on a currently mounted file system, it returns a success
status of zero. It should return a non-zero status.
- This network patch, which greatly improves Digital UNIX networking
performance, is targeted at high traffic Web server systems or any
system which handles a large number of TCP connections simultaneously,
ie. more than several thousand at one time.
- The kernel panics with a "kernel memory fault", typically in either the
vm_pg_alloc() or vm_zeroed_pg_alloc() routines.
- Fixes a problem in which network applications communicating to one of
the host's own addresses, may hang, or receive the error message:
no buffer space available
The problem occurs due to a queue full condition on the interface.
- Fixes a problem in which the the lastcomm accounting command doesn't print
the "S" flag at appropriate times. This patch also improves the performance
of lastcomm.
- This patch resolves a TCP/IP network hang due to IP Q ACK deadlock.
When this condition occurs the IP Q becomes full due to saturation.
Representative console messages indicating this condition are shown below:
SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.
- Fixes a performance problem that occurs with UFS file systems.
- Fixes a number of problems relating to signals and POSIX 1003.1b timers
in multi-threaded programs running on multi-processor systems. These
problems can result in missed timer-expiration signals and system crashes.
- Probe of isp fails intermittently during boot.
- Fixes a kernel memory fault in ether_output packet filter, when running
tcpdump.
- This patch resolves a TCP/IP network hang due to IP Q ACK deadlock. When
this condition occurs the IP Q becomes full due to saturation. Representative
console messages indicating this condition are shown below
SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.
- Fixes ICMP REDIRECTS. When an ICMP REDIRECT is received, the routing
table was updated properly, but the IP layer didn't use then new route
information.
- Fixes a problem in which the system can panic with "lock already owned by
thread"
- Fixes a problem that occurs on all systems that use networking system.
- This patch is a kernel fix for network sockets left in FIN_WAIT_1 state
forever. This patch contains a "tunable" kernel parameter. It is recommended
that only experienced system administrators attempt to set this parameter
from the default value.
- Fixes a problem that occurs when the system panics with the following error
message:
kernel memory fault
- Fixes a problem with the exec() system function. A shell script that
has "#! " as the first line of the script, invokes
the program but does not set the effective user id for the execution
of the program.
- Fixes a problem that can occur with programs linked with libaio.
These programs could dump core with a SIGSEGV signal or corrupt memory
when calling the close() function with a bad file descriptor value.
- This patch resolves a kernel memory fault.
- System panics with message: "vm_map_swapout: negative resident count".
- The user or sytem UAC_NOPRINT settings are ignored when an unaligned access
trap on a user address was taken while in kernel mode; the unwanted error
message is still printed.
- NetWorker Version 4.2c requires this patch for new fcntl functionality.
This layered product will not run desirably without this patch.
- This patch allows tuneablity for existing two level task swapping scheme.
- The ObjectStore application from Object Design, Inc. fails with the
following error:
"Fatal error Invalid argument(errno = 22)
munmap failed: cl_mmap:"
- Fixes a system crash when setting the date on SMP systems.
- Devices sometimes cannot be accessed by the system after getting selection
timeouts.
- Fixes a network socket problem with select() missing state changes on clients
from non-write to writable.
- Fixes some hangs that can occur during the "syncing disks..." portion of
panic processing, improves the reliability of getting a dump after a system
panic, and also makes it more likely that AdvFS buffers will be synced to
disk after a system panic.
- The vmstat(1) command displays negative numbers when used with the '-P'
option. Problem may not appear on all platorms or configurations. It is
dependent on how the system constructs various internal data structures.
- Prevents a "kernel memory fault" in bread() during sync operations.
- Fixes "kernel memory fault" panics from the kernel malloc() routine, and
threads hanging in vfs_busy() when file-on-file mounting (kernel option
FFM_FS) is used with fattach()/fdetach() or System V STREAMS.
PROBLEM: (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF410-039)
********
This patch fixes some hangs that may occur after the message "syncing disks..."
is printed when the system panics. When these hangs occur, the completion of
the "syncing disks..." message - the word "failed" or "done" does not get
printed, and the system does not take a dump.
In addition to fixing these known hangs, a timout mechanism is added to the
"syncing disks" logic that will improve the reliability of getting a dump by
using the system clock to break out of the "syncing disks" path and take
a dump if no progress is being made on reducing the number of buffers to be
flushed. The numbers printed periodically between the "syncing disks..."
and "done" messages are the number of buffers left to flush.
This patch also makes it more likely that AdvFS buffers will be flushed to
disk during the "syncing disks..." processing after a system panic. There
is still no guarantee that writes in progress at the time of a panic will be
completed.
PROBLEM: (QAR 49523) (Patch ID: OSF410-034)
********
The vmstat(1) command may display negative numbers when run with the '-P'
option. To reproduce the problem type: vmstat -P
NOTE: The problem may not exist on all platforms / configurations because
it is dependent on how the kernel build various internal data structures.
PROBLEM: (QAR 49556) (Patch ID: OSF410-405037)
********
A "kernel memory fault" panic will be seen originating from the malloc()
routine. The top stack entries will be as follows. Many different kernel
routines may appear in the stack below malloc().
panic("kernel memory fault")
trap()
_XentMM()
malloc()
This problem is due to malloc() bucket corruption that occurs when there are
racing fdetach()/ file-on-file unmounts. File-on-file mounting is most often
used with the fattach() library call and System V Environment pipes.
PROBLEM: (QAR 49556) (Patch ID: OSF410-405037)
********
Racing fdetach() or file-on-file unmounts can also cause threads to hang in
the kernel with the following stack trace.
0 thread_block()
1 vfs_busy()
2 dounmount()
3 unmount()
4 syscall()
5 _Xsyscall()
PROBLEM: (CLDs HPAQ92E5E,TKTR90455/QAR 49011) (Patch ID: OSF410-400100)
********
This patch prevents a "kernel memory fault" in the bread() routine while
performing sync operations.
The stack trace will look similar to the following:
0 boot() ["../../../../src/kernel/arch/alpha/machdep.c"]
1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c"]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c"]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s"]
4 bread() ["../../../../src/kernel/vfs/vfs_bio.c"]
5 iupdat() ["../../../../src/kernel/ufs/ufs_inode.c"]
6 ufs_sync() ["../../../../src/kernel/ufs/ufs_vfsops.c";
7 sync() ["../../../../src/kernel/vfs/vfs_syscalls.c"]
8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]
PROBLEM: (QAR 47666) (Patch ID: OSF410-405036)
********
Sometimes the system cannot contact a device when it should be able to.
The problem is that if a device got a selection timeout, the EDT structure
is released. The next time the system tries to access that device,
it fails if the device does not respond within the timeout period.
PROBLEM: (HPXQB6189/QAR 49949) (Patch ID: OSF410-400141)
********
This patch fixes a network socket problem with select() missing state changes
on clients from non-write to writable.
PROBLEM: (MCPM94D74, QAR 49067) (Patch ID: OSF410-400165)
********
Fixes system crash when setting the date for SMP systems.
A representative stack trace follows:
panic("resettodr: cpu not master")
["../../../../src/kernel/bsd/subr_prf.c":753,]
resettodr() ["../../../../src/kernel/arch/alpha/clock.c":322,]
setthetime() ["../../../../src/kernel/bsd/kern_time.c":543,]
settimeofday() ["../../../../src/kernel/bsd/kern_time.c":499,]
PROBLEM: (QAR 51688, CLD USG-04543) (Patch ID: OSF410-052)
********
The ObjectStore application from Object Design, Inc. fails with the following
error:
"Fatal error Invalid argument(errno = 22) munmap failed: cl_mmap:"
PROBLEM: (USG-04536,51700) (Patch ID: OSF410-059)
********
Idle processes display poor interactive responsiveness. this patch prevents
idle processes from being outswapped too soon.
PROBLEM: (QAR 36779) (Patch ID: OSF410-405054)
********
This patch fixes a problem that occurs when running the NetWorker Version 4.2c
application. The NetWorker application is unable to reset the atime (access
time) attribute on files being accessed. No errors or warnings are displayed.
Without this patch, NetWorker Version 4.2c will not perform well.
PROBLEM: (HPXQB6BA4) (Patch ID: OSF410-062)
********
This patch fixes a problem in which the user or system setting of UAC_NOPRINT
is ignored when an unaligned access trap is taken on a user address while
in kernel mode. When this is a common event due to a customer application,
the console and "messages" file can be flooded with error messages of the
sort show below:
Oct 19 03:20:18 dekalb vmunix: Unaligned kernel access va=0x140018554 pc=0xfffff
c00004f5f24 ra=0xfffffc000025bc80 inst=0xffffffff
PROBLEM: (QAR 49818) (Patch ID: OSF410-400127)
********
System panics with messgae: "vm_map_swapout: negative resident count".
The crash will most likely occur on a multi-processor system during
a heavy paging load.
panic("vm_map_swapout: negative resident count")
vm_map_swapout()
task_swapout()
task_swapout_thread()
PROBLEM: (CLD MCPMB7DEJ, QAR 50938) (Patch ID: OSF410-400197)
********
This patch resolves a kernel memory fault.
A representative stack trace follows:
panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753, ]
trap() ["../../../../src/kernel/arch/alpha/trap.c":1457, ]
_XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1392, ]
simple_lock_D() ["../../../../src/kernel/arch/alpha/lockprim.s":730, ]
u_anon_dupmcopy() ["../../../../src/kernel/vm/u_mape_anon.c":1603, ]
u_anon_dupmcopy() ["../../../../src/kernel/vm/u_mape_anon.c":1603, ]
u_anon_dup() ["../../../../src/kernel/vm/u_mape_anon.c":1321, ]
u_map_copyin() ["../../../../src/kernel/vm/vm_umap.c":2085, ]
vm_map_copyin() ["../../../../src/kernel/vm/vm_map.c":1691, ]
procfs_psinfo() ["../../../../src/kernel/procfs/procfs_subrs.c":2425, ]
procfs_ioctl() ["../../../../src/kernel/procfs/procfs_ioctl.c":301, ]
vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165, ]
procfs_ioctl_interface() ["../../../../src/kernel/procfs/procfs_ioctl.c":1716, ]
ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":426, ]
ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374, ]
PROBLEM: (QAR 51161, QAR 51813) (Patch ID: OSF410-063)
********
This patch corrects problems encountered when using signals with multi-thread
programs. Specifcally, three problem may be encountered, all of them usually
resulting in an application hang:
1. Missed thread-specific signals. These are signal sent via the pthread_kill()
function. Under extremely intensive use, a signal sent by pthread_kill()
can be lost. This will usually manifest itself as an application hang, as
expected signal goes unreceived.
2. Inconsistent compute-bound hangs in the libpthreads.so. Typically, a stack
trace for such a hang would have the following mutex-related frames at the
top of its stack:
0 pthread_mutex_unblock()
1 __pthread_mutex_unlock()
2 (unknown)()
3 free()
.
.
.
The frames below the mutex frames could be any routine that calls
pthead_mutex_unlock().
3. Unexpected error return from system calls. When using process-level signals,
certain system calls may return unexpectedly with an EINTR error without a
signal actually having been delivered. Typcial victims of this problem are
are the sigwait() and read() functions. Particularly in the case of read(),
an application is likely to reissue the system call without noticiing the
error, resulting in a compute-bound loop.
PROBLEM: (EVT101963, QAR 52024) (Patch ID: OSF410-405062)
********
The kernel panics with a "kernel memory fault". Typical stack traces will
panic in either vm_zeroed_pg_alloc() or vm_pg_alloc() as shown below:
> 0 boot src/kernel/arch/alpha/machdep.c : 2361
1 panic src/kernel/bsd/subr_prf.c : 791
2 trap src/kernel/arch/alpha/trap.c : 1457
3 _XentMM src/kernel/arch/alpha/locore.s : 1388
4 vm_zeroed_pg_alloc src/kernel/vm/vm_resident.c : 1289
5 vm_anon_page_alloc src/kernel/vm/vm_anonpage.c : 119
6 anon_pagezero_alloc src/kernel/vm/vm_anon.c : 448
7 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 968
8 u_anon_fault src/kernel/vm/u_mape_anon.c : 861
9 u_map_fault src/kernel/vm/vm_umap.c : 501
10 vm_fault src/kernel/vm/vm_fault.c : 134
11 trap src/kernel/arch/alpha/trap.c : 1467
12 _XentMM src/kernel/arch/alpha/locore.s : 1388
> 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 414
1 panic src/kernel/bsd/subr_prf.c : 703
2 event_timeout src/kernel/arch/alpha/cpu.c : 811
3 xcpu_puts src/kernel/bsd/subr_prf.c : 844
4 printf src/kernel/bsd/subr_prf.c : 379
5 panic src/kernel/bsd/subr_prf.c : 753
6 trap src/kernel/arch/alpha/trap.c : 1457
7 _XentMM src/kernel/arch/alpha/locore.s : 1388
8 vm_pg_alloc src/kernel/vm/vm_resident.c : 1162
9 ubc_alloc src/kernel/vfs/vfs_ubc.c : 3278
10 ubc_page_alloc src/kernel/vfs/vfs_ubc.c : 2240
11 ubc_lookup src/kernel/vfs/vfs_ubc.c : 1779
12 page_lookup src/kernel/msfs/bs/bs_buffer2.c : 1041
13 seq_ahead src/kernel/msfs/bs/bs_buffer2.c : 5258
14 seq_ahead_cont src/kernel/msfs/bs/bs_buffer2.c : 5013
15 bs_refpg_int src/kernel/msfs/bs/bs_buffer2.c : 1867
16 bs_refpg src/kernel/msfs/bs/bs_buffer2.c : 1596
17 fs_read src/kernel/msfs/fs/fs_read_write.c : 1549
18 msfs_read src/kernel/msfs/osf/msfs_vnops.c : 1883
19 vn_read src/kernel/vfs/vfs_vnops.c : 864
20 rwuio src/kernel/bsd/sys_generic.c : 1217
21 read src/kernel/bsd/sys_generic.c : 1167
22 syscall src/kernel/arch/alpha/syscall_trap.c : 540
23 _Xsyscall src/kernel/arch/alpha/locore.s : 1173
PROBLEM: (QAR 50693, QAR 49421) (Patch ID: OSF410-400216)
********
This patch corrects a problem with the exec() system function. A shell script
that has "#! " as the first line of the script, invokes the
the program but does not set the effective user id for the execution of the
program. For example:
$ cat myprog.c
#include
main()
{
printf("geteuid() return effective user ID of the calling
process=%d\n",geteuid());
}
$ cat test.sh
#!./myprog
echo "done with myprog"
As root:
# chmod 4755 myprog
# chown root myprog
As user ww
$ ./myprog
geteuid() return effective user ID of the calling process=0
$ ./test.sh
geteuid() return effective user ID of the calling process=7301
In this case ./test.sh should return an euid of 0.
PROBLEM: (CLD EVT101664) (Patch ID: OSF410-400232)
********
This patch fixes a performance problem that occurs with UFS file systems.
Data written to a file greater than 32 GB in length will be slower than
data written to the file when it is less than 32 GB in length.
PROBLEM: (HPAQC07YV) (Patch ID: OSF410-400208)
********
This patch fixes a problem that occurs when the system panics with the
following error message:
kernel memory fault
The following is a typical stack trace of the system panic:
0 boot() [../../../../src/kernel/arch/alpha/machdep.c]
1 panic("kernel memory fault") [../../../../src/kernel/bsd/subr_prf.c]
2 trap() [../../../../src/kernel/arch/alpha/trap.c]
3 _XentMM() [../../../../src/kernel/arch/alpha/locore.s]
4 _svcauth_unix() [../../../../src/kernel/rpc/svc_auth_unix.c]
5 _authenticate() [../../../../src/kernel/rpc/svc_auth.c]
6 nfs_rpc_recv() [../../../../src/kernel/rpc/svc.c]
7 nfs_rpc_input() [../../../../src/kernel/rpc/svc.c]
8 nfs_input() [../../../../src/kernel/nfs/nfs_server.c]
9 nfs_thread() [../../../../src/kernel/nfs/nfs_server.c]
PROBLEM: (QAR 50697, MGO102332, FNO100130) (Patch ID: OSF410-400198)
********
This patch fixes a number of problems relating to signals and POSIX
1003.1b timers in multi-threaded programs running on multi-processor systems.
These problems can result in missed timer-expiration signals and system
crashes. These issues involve synchronizing timer creation, timer
deletion, and timer reset within multi-threaded programs.
Two distinct crashes are typical of the problems.
Here's a sample of the first crash, a signal panic:
panic (cpu 0): psig: catch not set
With the following stack trace:
> 0 boot
1 panic
2 psig
3 syscall
4 _Xsyscall
A sample of the second crash is shown in the following example:
from vmcore.3 :
.
.
.
simple_lock: time limit exceeded
.
.
.
pc of caller: 0xfffffc000024a5a4
lock address: 0xfffffc003d93b210
current lock state: 0x000000000043af85
(cpu=0,pc=0xfffffc000043af84,busy)
.
.
.
panic (cpu 2): simple_lock: time limit exceeded
While a stack trace would show:
kernel stack of CPU 0
> 0 boot
1 panic
2 event_timeout
3 simple_lock_miss
4 netisr_timeout
5 softclock_scan
6 lwc_schedule
7 thread_preempt
8 boot
9 panic
10 cpu_ip_intr
11 _XentInt
12 swap_ipl_preempt_check
13 wanTimerSysTick
.
.
.
kernel stack of CPU 1
> 0 stop_secondary_cpu ...
1 panic :
2 cpu_ip_intr : THIS PART OF THE KERNEL STACK
3 _XentInt : IS VERY TYPICAL FOR THIS CLASS
4 sigq_enqueue_tail : OF CRASHES.
5 psignal_internal :
6 psx4_tod_expire_sig ..:
7 psignal_lwc
8 lwc_schedule
9 do_preemption
10 simple_unlock_preempt
11 sigwaitprim
12 syscall
13 _Xsyscall
.
.
.
kernel stack of CPU 2
> 0 stop_secondary_cpu
1 panic
2 event_timeout
3 xcpu_puts
4 printf
5 panic
6 simple_lock_fault
7 simple_lock_time_violation
8 psx4_set_todtimer
9 syscall
10 _Xsyscall
.
.
.
kernel stack of CPU 3
> 0 stop_secondary_cpu
1 panic
2 cpu_ip_intr
3 _XentInt
4 swap_ipl_preempt_check
5 netisr_thread
6 wanTimerTick
.
.
.
This patch closes MP race conditions for multi-threaded use of POSIX
timers and signals.
PROBLEM: (MCPMA986D) (Patch ID: OSF410-405044)
********
This patch is a kernel fix for network sockets left in FIN_WAIT_1 state forever.
This patch contains a "tunable" kernel parameter. It is recommended that only
experienced system administrators attempt to set this parameter from the
default value.
How to recognize this problem.
This is an example of the problem with tcpdump running in the background
listening on the destination ip address shown in the netstat output.
# netstat -An | grep 203.232.10.221
Active Internet connections
PCB Proto Recv-Q Send-Q Local Address Foreign Address (state)
94276c00 tcp 0 759 192.86.154.82.80 203.232.10.221.162
FIN_WAIT_1
9418ef00 tcp 0 759 192.86.154.82.80 203.232.10.221.162
FIN_WAIT_1
13:28:03.472384 www-2.us.oracle.com.80 > 203.232.10.221.1626: . 0:1(1) ack 1
win 33232
13:28:12.973072 www-2.us.oracle.com.80 > 203.232.10.221.1623: . 0:1(1) ack 1
win 33232
What is observed here is the destination is clearly dead. The source is
sending an ACK to the destination looking for his ACK of our FIN. This is
commonly refered to as "persist mode". A socket in this state will never
timeout and system resources associated with it will not be released.
The new kernel modification to tcp_timer.o can be "tuned" by dbx'ing the
tcp_keepidle parameter on the system. By default, this is set to 14400
1/2 seconds (2 hours). It can be easily set to any value appropriate for
the system to "balance" the number of sockets in FIN_WAIT_1 state at any
time. The system may always have some sockets in FIN_WAIT_1 as well as
CLOSE_WAIT, this is NORMAL. What you don't want is a large number of sockets
in FIN_WAIT_1 forever. It is not recommended that tcp_keepidle be set to
less than 5 minutes on the system.
Reference the man page to dbx for guidelines when using the dbx command.
PROBLEM: (ZUO101015/QAR 49750) (Patch ID: OSF410-405053)
********
This patch fixes ICMP REDIRECTS. When an ICMP REDIRECT is received, the
routing table was updated properly, but the IP layer didn't use the new route
information.
PROBLEM: (CLD MCPMB04E3) (Patch ID: OSF410-405059)
********
This patch resolves a TCP/IP network hang due to an IP Q ACK deadlock. When
this condition occurs the IP Q becomes full due to saturation. Representative
console messages indicating this condition are shown below:
SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.
PROBLEM: (CA7Q10994) (Patch ID: OSF410-049)
********
This patch fixes a problem that occurs on all systems that use networking
services.
The problem can be seen when a system attempts to ping a Digital UNIX Alpha
system connected to a token ring network and the ping uses a message size that
requires fragmentation. The Digital UNIX Alpha system receiving the ping
cannot respond. The token ring driver displays the following error message
to the console and resets the token ring adapter:
List Error in transmit
PROBLEM: (HPXQB4C4B) (Patch ID: OSF410-400186)
********
This patch fixes a problem in which the system can panic with "lock already
owned by thread". A typical stack trace shows:
boot
panic
lock_fault
lock_write
solock
socket_send
ip_mforward
ip_output
rip_output
raw_usrreq
rip_usrreq
sosend
sendit
sendto
syscall
PROBLEM: (CLD MCPMB04E3) (Patch ID: OSF410-400233)
********
This patch resolves a TCP/IP network hang due to an IP Q ACK deadlock.
When this condition occurs the IP Q becomes full due to saturation.
Representative console messages indicating this condition are shown below:
SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.
PROBLEM: (CLD: MCPM3028N) (Patch ID: OSF410-400250)
********
This patch fixes a problem in which network applications communicating to
one of the host's own addresses, may hang, or receive the error message:
no buffer space available
The problem occurs due to a queue full condition on the interface.
In an Available Server (ASE) or TruCluster environment, the daemons will no
longer be able to communicate with each other, and the asemgr utility will
appear to hang.
PROBLEM: (MCPMC07S7) (Patch ID: OSF410-400201)
********
This patch fixes a kernel memory fault in ether_output packet filter, when
running tcpdump.
A representative stack trace of the 'tcpdump' process following:
read_io_port() src/kernel/io/dec/pci/pcia.c : 707
fta_poll_cmd_req() src/kernel/io/dec/netif/if_fta.c : 3065
ftaioctl() src/kernel/io/dec/netif/if_fta.c : 1831
enetSetIfflags() src/kernel/net/pfilt.c : 3311
decCopyAllCount() src/kernel/net/pfilt.c : 3367
Pfilt_close() src/kernel/net/pfilt.c : 1376
speclose() src/kernel/vfs/spec_vnops.c : 2486
spec_close() src/kernel/vfs/spec_vnops.c : 2616
ufsspec_close() src/kernel/ufs/ufs_vnops.c : 3632
vn_close() src/kernel/vfs/vfs_vnops.c : 1280
closef() src/kernel/bsd/kern_descrip.c : 1539
close() src/kernel/bsd/kern_descrip.c : 1217
PROBLEM:(CLD HPXQ87202,QAR 49448,QAR 49474,QAR 49475) (Patch ID: OSF410-400242)
********
This patch fixes a problem in which the the lastcomm accounting command
doesn't print the "S" flag at appropriate times. This patch also improves
the performance of lastcomm.
The problem was that the kernel did not properly update the accounting field
that prints the "S" flag. The "S" flag should be printed for each command
that is run with an effective user id of 0. Commands that are set-user-id
to root, will print the "S" flag. Also, commands that are executed by root,
but are not set-user-id, will print the "S" flag. Therefore, when "S" is
printed from lastcomm for a certain command, it means that the user had root
privileges at some time during the execution of the command.
The algorithm used by lastcomm has been enhanced to improve its performance.
PROBLEM: (HGOBB0043, HGOBB0597) (Patch ID: OSF410-405045)
********
Intermittently, the probe of an isp will fail during a boot. This happens
maybe once in 20 system boots, so a workaround is to try the boot again.
A typical console listing looks like this when it fails:
.
.
.
Created FRU table configuration errorlog packet
tiop0 at tlsb0 node 8
tiop0: cpu interrupt mask being set as 1.
pci0 at tiop0 slot 0
isp0 at pci0 slot 0
isp0: QLOGIC ISP1020 - Differential Mode
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_mailbox complete
Timeout on mailbox command completion scheduling chip reinit
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_init
Mailbox operations not functional for common init
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_probe
Common init failure - Failing probe
isp0: Not probed.
isp in slot 0 not configured.
.
.
.
PROBLEM: (Patch ID: OSF410-068)
********
This network patch, which greatly improves Digital UNIX networking performance
is targeted at high traffic Web server systems or any system which handles a
large number of TCP connections simultaneously, ie. more than several thousand
at one time.
The summary of improvements include:
Network kernel SMP locking improvements
Increased throughput due to reduced lock contention throughout
network stack on multi-processor (SMP) systems
Socket code improvements
Improved performance in socket listen queue handling
somaxconn, sominconn listen backlog support was increased
from 32K to 64K maximum
TCP code improvements
Fully dynamic TCP hash table, can change size on the fly
without having to reboot (tcbhashsize) support for TCP
hash table size larger than 1024 (tcbhashsize) improved
TCP timer algorithm eliminates a large percentage of the
processing overhead needed to handle the tcp timer task
more efficient port allocation code decreases outgoing
connection overhead (ipport_userreserved) randomized TCP
initial sequence number IP reassembly fix for >12Gb memory
systems and other minor TCP/IP bug fixes
Kernel malloc improvements
Improved kernel malloc pool performance on SMP platforms
Kernel select improvements
Improved kernel select performance on SMP platforms when many
open file descriptors are selected simultaneously
Additional kernel network tunable variables (using sysconfig):
sobacklog_drops
sobacklog_hiwat
somaxconn_drops
ipport_userreserved
tcp_rexmit_interval_min
tcp_cwnd_segments
tcp_keepalive_default
PROBLEM: (QAR 50363) (Patch ID: OSF410-400235)
********
This patch fixes a problem with the fsck command. When fsck is run on a
a non-existent file system or on a currently mounted file system, it returns
a success status of zero. It should return a non-zero status.
An example where this problem is exhibited is shown here:
# fsck /dev/rz2a
/sbin/ufs_fsck /dev/rz2a
** /dev/rrz2a
Error: /dev/rrz2a or an overlapping partition is open.
FSCK CANNOT BE RUN ON AN ACTIVE FILESYSTEM.
# echo $?
0
ALSO:
# fsck /mnt
/sbin/ufs_fsck /mnt
Can't make sense out of name /mnt
# echo $?
0
PROBLEM: (QAR 46424) (Patch ID: OSF410-400221)
********
This patch fixes a problem in which the UFS property list can become corrupted
To reproduce this problem, complete the following steps:
1. Create a relatively large property value on a file.
2. Create another property value on the same file.
B
3. Change the property value created in Step 1 to a smaller value.
4. Run fsck with the -o flag.
The fsck command reports that the file system is corrupted and displays the
following error message:
** Phase 1 - Check Blocks and Sizes
PROPERTY LIST BLOCK CORRUPTED I=3
CLEAR? [yn]
PROBLEM: (TKTB68852) (Patch ID: OSF410-405068)
********
This patch fixes a performance regression that may occur as a result of v4.0b
patch OSF400-405045. To date this performance regression has been reported only
on the Noritake platform and on the single-ended KZPBA adapter used on the
Rawhide platform.
This patch also implements HSZ70 support for those system that have the
hardware installed.
PROBLEM: (MCPM11KK6) (Patch ID: OSF410-405058-1)
********
This patch provides support for the fuser utility. This utility displays a list
of processes that are holding references to a file on the file system that
cannot be unmounted. This utility can also be used to terminate a process so
the file system can be unmounted.
FILE(s):
/usr/sbin/audit_tool subset OSFBASE410
CHECKSUM: 29601 168 RCSfile: audit_tool.c RCS: 1.1.30.2
/sys/BINARY/arch_alpha.mod subset OSFHWBIN410
CHECKSUM: 34040 442
/sys/BINARY/arch_alphapmap.mod subset OSFHWBIN410
CHECKSUM: 62847 181
/sys/BINARY/cam.mod subset OSFHWBIN410
CHECKSUM: 53174 416
/sys/BINARY/cam_disk.mod subset OSFHWBIN410
CHECKSUM: 58279 291
/usr/sys/include/io/cam/cam_disk.h subset OSFBINCOM410
CHECKSUM: 05627 27 RCSfile: cam_disk.h RCS: 1.1.62.2
/sys/BINARY/cam_isp1020.mod subset OSFHWBIN410
CHECKSUM: 23196 98
/sys/BINARY/cam_sim.mod subset OSFHWBIN410
CHECKSUM: 03476 192
/usr/bin/lastcomm subset OSFBASE410
CHECKSUM: 07525 24 RCSfile: lastcomm.c RCS: 4.2.20.2
/usr/sys/include/io/cam/qlogic/isp1020.h subset OSFBINCOM410
CHECKSUM: 59913 43 RCSfile: isp1020.h RCS: 1.1.80.3
/usr/sys/include/io/cam/ccfg.h subset OSFBINCOM410
CHECKSUM: 26623 11 RCSfile: ccfg.h RCS: 1.1.21.2
/usr/sys/include/sys/fcntl.h subset OSFBINCOM410
CHECKSUM: 17491 10 RCSfile: fcntl.h RCS: 4.2.46.3
/usr/sys/include/sys/fcntl1.h subset OSFBINCOM410
CHECKSUM: 18748 3 RCSfile: fcntl1.h RCS: 1.1.2.2
/usr/sys/include/io/cam/sim.h subset OSFBINCOM410
CHECKSUM: 62806 35 RCSfile: sim.h RCS: 1.1.61.2
/sys/BINARY/ether.mod subset OSFBIN410
CHECKSUM: 14908 133
/sys/BINARY/ffm_fs.mod subset OSFBIN410
CHECKSUM: 02865 24
/sys/BINARY/inet.mod subset OSFBIN410
CHECKSUM: 44940 283
/sys/BINARY/loop.mod subset OSFBIN410
CHECKSUM: 27060 15
/sys/BINARY/nfs.mod subset OSFBIN410
CHECKSUM: 52471 424
/usr/sys/include/ufs/fs_proto.h subset OSFBINCOM410
CHECKSUM: 39564 12 RCSfile: fs_proto.h RCS: 1.1.30.2
/usr/sys/include/ufs/inode.h subset OSFBINCOM410
CHECKSUM: 49905 13 RCSfile: inode.h RCS: 4.3.39.2
/usr/sys/include/sys/siginfo.h subset OSFBINCOM410
CHECKSUM: 65468 12 RCSfile: siginfo.h RCS: 1.1.32.2
/usr/sys/include/sys/signal.h subset OSFBINCOM410
CHECKSUM: 47393 25 RCSfile: signal.h RCS: 4.3.29.4
/usr/sys/include/sys/time.h subset OSFBINCOM410
CHECKSUM: 08607 9 RCSfile: time.h RCS: 4.4.46.2
/usr/sys/kern/lockinfo.c subset OSFBINCOM410
CHECKSUM: 55913 96 RCSfile: lockinfo.c RCS: 1.1.346.2
/sys/BINARY/presto.mod subset OSFBIN410
CHECKSUM: 32549 148
/sys/BINARY/procfs.mod subset OSFBIN410
CHECKSUM: 14471 184
/sys/BINARY/re_xcr.mod subset OSFHWBIN410
CHECKSUM: 58541 66
/sys/BINARY/socket.mod subset OSFBIN410
CHECKSUM: 02540 3
/sys/BINARY/std_kern.mod subset OSFBIN410
CHECKSUM: 47064 1098
/sys/BINARY/ufs.mod subset OSFBIN410
CHECKSUM: 00723 325
/sbin/ufs_fsck subset OSFBASE410
CHECKSUM: 65429 472
/usr/sbin/ufs_fsck subset OSFBASE410
CHECKSUM: 09825 104
/sys/BINARY/vfs.mod subset OSFBIN410
CHECKSUM: 04260 416
/usr/sys/vfs/vfs_conf.c subset OSFBINCOM410
CHECKSUM: 46207 11 i RCSfile: vfs_conf.c RCS: 4.2.52.3
/sys/BINARY/vm.mod subset OSFBIN410
CHECKSUM: 64566 425
/usr/sbin/ifconfig subset OSFCLINET410
CHECKSUM: 51561 40
/usr/sys/include/netinet/tcp_var.h subset OSFBINCOM410
CHECKSUM: 55999 14 RCSfile: tcp_var.h RCS: 4.2.42.2
/usr/sys/include/netinet/tcp_timer.h subset OSFBINCOM410
CHECKSUM: 35982 8 RCSfile: tcp_timer.h RCS: 4.2.29.2
/usr/sys/include/netinet/ip_var.h subset OSFBINCOM410
CHECKSUM: 03575 10 RCSfile: ip_var.h RCS: 4.4.28.2
/usr/sys/include/netinet/proto_inet.h subset OSFBINCOM410
CHECKSUM: 37937 10 RCSfile: proto_inet.h RCS: 4.3.45.2
/usr/sys/include/netinet/in_pcb.h
CHECKSUM: 57265 11
/usr/sys/include/net/if.h subset OSFBINCOM410
CHECKSUM: 46497 43 RCSfile: if.h RCS: 4.3.91.2
/usr/sys/include/sys/malloc.h subset OSFBINCOM410
CHECKSUM: 46851 18 RCSfile: malloc.h RCS: 1.1.58.2
/usr/sys/include/sys/socketvar.h subset OSFBINCOM410
CHECKSUM: 62432 14 RCSfile: socketvar.h RCS: 4.2.54.2
/usr/sys/include/sys/user.h subset OSFBINCOM410
CHECKSUM: 20092 24 RCSfile: user.h RCS: 4.3.76.2
===============================================================================
This patch fixes a problem in the comm command where it will split long line(s)
in a file by inserting a that exceeds 255 characters. In
some cases, characters will be truncated.
PROBLEM: (QAR 53754 ) (Patch ID: OSF410-405095)
********
Also, the Problem Description needs to be modified to say something like the
following:
There is a problem in the comm command where it will split long line(s) in a
file by inserting a that exceeds 255 characters. In some
cases, characters will be truncated.
For example, if you execute the following command on a Digital Unix v4.0 or
greater:
# comm -12 /etc/sysconfigtab /etc/sysconfigtab > outfile
When you view the outfile, you will notice that the long lines under the
"# %%%PCI" header are split. In this case the lines were being split after
Sub_Vid_Mo_Fla and before - O on lines beginning with "PCI_Option = PCI_SE_Rev".
FILE(s):
/usr/bin/comm subset OSFBASE410
CHECKSUM: 55355 24 RCSfile: comm.c RCS: 4.2.16.2
===============================================================================
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: (SSRT0296U) (Patch ID: OSF400-189B)
********
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.
FILE(s):
/usr/sbin/named subset OSFINET410
CHECKSUM: 03940 184
/usr/sbin/named-xfer subset OSFINET410
CHECKSUM: 14907 48 RCSfile: named-xfer.c RCS: 4.2.16.2
/usr/sbin/screend subset OSFINET410
CHECKSUM: 15919 392 RCSfile: screend.c RCS: 1.1.5.2
===============================================================================
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: (SSRT0296U) (Patch ID: OSF400-189C)
********
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.
FILE(s):
/usr/lib/uucp/uucico subset OSFUUCP410
CHECKSUM: 56123 600
/usr/lib/uucp/uucleanup subset OSFUUCP410
CHECKSUM: 46222 424 RCSfile: uucleanup.c RCS: 4.3.10.2
/usr/bin/uucp subset OSFUUCP410
CHECKSUM: 00851 448 RCSfile: uucp.c RCS: 4.3.10.3
RCSfile: uucpdefs.c RCS: 4.3.8.2
RCSfile: uucpname.c RCS: 4.3.7.2
/usr/sbin/uucpd subset OSFUUCP410
CHECKSUM: 20565 376 RCSfile: uucpd.c RCS: 4.3.8.2
© Digital Equipment Corporation, 1995. The DIGITAL logo is a trademark
of Digital Equipment Corporation. All other trademarks are the property of
their respective owners.
Creation Date: Mon Aug 11, 1997