|
============================ << START OF PATCH >> ==============================
New PatchID: 47.00
PATCH ID: OSF410-400154 SUBSET(s): OSFBASE410 OSFCMPLRS410
********************************************************************************
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)
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 <sys/ioctl.h>
#include <stdio.h>
#include <string.h>
#include <utmp.h>
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: (49260) (Patch ID: OSF410-400106)
********
Customer applications that repeatedly call gethostent(), when run on
systems configured to use YP and/or bind services for host entries, will
see only the entries in the local /etc/hosts file. The problem is not
present for similar routines such as gethostbyname().
The only way to reproduce the problem is to write a program that repeatedly
calls gethostent() and then verify that it does not return all the entries
present in the YP and bind databases served to the machine.
PROBLEM: (ULC-43) (Patch ID: OSF410-400119)
********
The customer's application sets a timer to go off every 200 milliseconds
via a call to setitimer(). It then loops indefinitely, calling a function
that does a setjmp() and then calling a function that does a longjmp(). On
Digital UNIX V4.0 r386 (SSB), the application fails with a segmentation
fault after a variable number of loop iterations.
PROBLEM: (QAR 49787) (Patch ID: OSF410-400133)
********
A multithreaded application that calls any of the system database "get*"
functions (gethostent, getservent, etc.) and that calls fork(), may deadlock.
DECladebug will show a thread blocking on a mutex lock with the call to fork()
on its call stack, while another thread will also be stuck in the mutex
blocking function with a function name like gethostbynam() on its stack.
Other threads may or may not be stuck on other mutex locks. The two threads
in question will never progress. Any subsequent calls to fork will block
forever.
PROBLEM: (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: (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: (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.
FILE(s):
/shlib/libc.so subset OSFBASE410
CHECKSUM: 55556 1542
/shlib/libc_r.so subset OSFBASE410
CHECKSUM: 55556 1542
/usr/ccs/lib/libc.a subset OSFCMPLRS410
CHECKSUM: 52325 1952
/usr/ccs/lib/libc_r.a subset OSFCMPLRS410
CHECKSUM: 52325 1952
---------------------------------------------
|