 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHCO_27608
Patch Description: s700_800 11.00 libc cumulative patch
Creation Date: 02/08/12
Post Date: 02/08/26
Repost: 05/06/17
The Special Installation Instructions field of the patch
documentation was modified to provide a workaround to a
potential issue if the /etc/utmpx file is corrupted.
Hardware Platforms - OS Releases:
s700: 11.00
s800: 11.00
Products: N/A
Filesets:
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
ProgSupport.PROG-AX-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
Automatic Reboot?: No
Status: General Superseded
Critical:
Yes
PHCO_27608: HANG
PHCO_25976: ABORT CORRUPTION HANG
PHCO_25707: ABORT HANG
PHCO_24723: ABORT
PHCO_24148: CORRUPTION ABORT
PHCO_13283: CORRUPTION
Category Tags:
defect_repair enhancement general_release critical
halts_system corruption
Path Name: /hp-ux_patches/s700_800/11.X/PHCO_27608
Symptoms:
PHCO_27608:
Application hangs in free()/realloc().
JAGae26049; SR 8606261730
PHCO_25976:
A user built perl executable aborted when using
getpwent(3C) API.
JAGae00927; SR 8606231691
gethostbyname(3N) routine returns incorrect results in
multi-threaded environment when it is called with an
IP address as the argument.
JAGae19108; SR 8606254777
On a system with duplicate utmpx entries, logname(1)
command and getlogin(3C) API were reporting incorrect
login-names for the user.
JAGae07413; SR 8606238389
strtod(3C) returns the wrong end pointer, when the
first argument is "infinity".
JAGae26691; SR 8606262356
Daemon programs which make calls to getpwnam(3C),
getpwuid(3C), getgrgid(3C), or getgrnam(3C) may hang.
JAGae21220; SR 8606256907
Whenever large number(for example: more than 2000) of
logins or logouts happen simultaneously,response time
of the system is very slow (several minutes).
JAGac42568; SR 8606125689
Application crashes when threads are created with
non default stack size
JAGae10553; SR 8606243323
PHCO_25707:
Application which uses localtime() aborts when built with -z
and environment variable TZ set to last entry in
/usr/lib/tztab.
JAGad94442; SR 8606225355
Deadlock occurs when one thread in the process is performing
a blocking read (via stdio interfaces like fgets) and before
the blocking thread could return, another thread performs a
fork().
JAGad68247; SR 8606199060
PHCO_24723:
Performance degradation of mktime ()
JAGad75245; SR 8606206070
delmntent libc routine deletes the entire mnttab contents.
JAGad81071; SR 8606211883
regexec() does not handle multibyte characters correctly.
JAGad74356; SR 8606205180
directory (3C) API's mutex contention.
JAGad82310; SR 8606213123
Default SBA support for C++ applications
JAGad74141, JAGad84551; SR 8606204965, 8606215364
memchr returns incorrect result when the count is -ve
JAGad86533; SR 8606217381
memchr core dump
JAGad63604; SR 8606194394
When a file stream is opened in read-only mode, putw()
reports a success though sets the errno to EBADF.
JAGad72144; SR 8606202970
When a file stream is opened in write-only mode, an
immediate fread() reported failure but an fread() which was
followed by a fwrite() reported success.
JAGad72400; SR 8606203226
rlogin with long host name causes it to exit, giving
"received signal 11" message.
JAGaa27187;
remsh and rexec with long user name dumps core.
JAGad27794; SR 8606158464
When an application creates more than 5000 threads, there is
a possibility that res_query() dumps core. As a result of
which, the application exits.
JAGad81970; SR 8606212783
PHCO_24148:
Multithreaded application core dumps sometimes when it uses
the Name Service Switch calls like getXXent and endXXent.
JAGad65825; SR 8606196622
M_BLOCK behavior for malloc not working correctly.
JAGad55731; 8606186527
mallinfo(3C) doesn't give correct memory statistics if the
application is multithreaded and uses multiple arenas.
JAGad34660; 8606165366
ptsname corrupts heap SIGBUS may result.
JAGad46861; 8606177629
When environment variable TZ is not set, the variables
tzname[2] and timezone is set to hard coded values
corresponding to Eastern Standard Time.
JAGab20870; 8606239637
valloc fails when memory available in multithreaded
application.
JAGad47526; 8606178299
New feature and not a defect. Initialized TLS support in
libc
JAGad49168; 8606179946
fstyp returns "unknown_fstyp" on VxFS version 4 disk layout
file system
JAGad57721; 8606188513
strncasecmp() behaves differently with libc patches for
S-Chinese locale
JAGad66064; 8606196866
Trusted system calls made on an 11.0 NIS system causes a
SIGSEGV core dump.
Using "dns" as a source for databases other than "hosts"
causes a SIGSEGV core dump.
JAGad41604; 8606172344
PHCO_23770:
For those PA-32bit Threaded C Applications which uses C++
plugins and pthread/cma calls in static
constructor/destructor, may happen that destructors will be
called twice. Non-threaded PA-32 bit applications do not
have this problem.
JAGad55189; SR 8606185984
PHCO_22923:
No externally supported method to pthread safe dynamically
loaded libs.
JAGab69119; SR 8606102984
User cannot use C++ runtime library on 32 bit application
without either using a C++ main program or explicitly invoke
the C++ runtime library's initialization routine, _main,
from the C ( or Fortran ) main program.
JAGad41440; SR 8606172179
gettimeofday is very slow for certain vendors who use it for
time stamping.
JAGad44410; SR 8606175166
Global symbols in libc can conflict with one in program
causing SIGBUS. Customer can experience this problem if
he/she uses his/her own global variable "alpha". It is very
likely that customers can have alpha as their global
variable.
JAGad33756; SR 8606164457
sigwait() does not work as cancellation point if the thread
is cancelled after it enters __sigwait_sys().
JAGad39745; SR 8606170481
memmove() failing for data near to a quadrant boundary.
JAGac87878; SR 8606129543
regcomp(3C) function fails to detect an extended regular
expression match in the input data.For example,If the
pattern is "%|^xyz" and the string is te%st, it gives Found
No Match.
JAGad31456; SR 8606162140
seekdir core dumps when compiled with -z option
JAGac78889; SR 8606128089
Purify reports "Uninitialized Memory reads" in readdir_r
JAGac95112; SR 8606130241
Trying to access the freed memory in closedir.c is causing
the core dump.
JAGad21880; SR 8606152550
snprintf() does not handle length of zero properly.
JAGad12471; SR 8606143128
regerror() may dump core for some values of error code
JAGad02475; SR 8606133330
PHCO_22314:
Data corruption in large malloc.
JAGad25621; SR 8606156311
strftime() to slow in multi-threaded applications
(On V-class systems).
JAGac86555; SR 8606129009
JFS 3.3 commands compiled with a libc stub for acl() system
call fail on files larger than 2GB. This was particulary
noted in setacl and getacl commands, however any command or
user compiled program using acl() could be affected. The
error code returned is EOVERFLOW.
JAGad09568; SR 8606140246
sed(1) hangs in non-C locale for some patterns.
awk sub pattern does not work well under non-C locales.
JAGad05149,JAGac56665; SR 8606136018,8606126100
When the system runs out of memory, call to regcomp(3C) will
result in bus error.
JAGad03415; SR 8606134279
Calling the getgrent or getpwent repeatedly causes core dump
with SIGBUS error when there is no nsswitch.conf file.
JAGad11220; SR 8606141866
strncat truncates string.
JAGad16345; SR 8606147002
PHCO_22076:
The default resolver configurable timeout is large
(5 Seconds). VUE may take a long time to come up when
the system is not connected to network.
JAGaa27175; SR 5003424531
PHCO_20765:
Fork fails for threaded applications when an older
pthread library (11.00 LR) is installed on the system.
JAGac40398; SR 8606125006
Threaded programs using third-party mallocs abort.
JAGac40401; SR 8606125009
Unsupported mixed dependencies on both archive and
shared libc fail.
JAGac40402; SR 8606125010
Sporadic valloc failure in threaded applications.
JAGac40711; SR 8606125320
Multi-threaded applications that create threads
sequentially encounter excessive process memory growth
and malloc() failure even when the process heap has
plenty of free memory.
JAGac40903; SR 8606125513
PHCO_20763:
This is a SP patch version of PHCO_20765.
PHCO_20555:
system() is slow in multi-threaded applications,
possibly leading to unusable systems due to swapping
activity if called from large 64bit processes.
JAGab78389; 8606108045
sigaction() called from a signal handler in a multi-
threaded application can result in hangs.
JAGab81794; 8606109096
In applications using large malloc, malloc can return
an invalid quad 2 "buffer" that overlays the stack,
resulting in stack corruption.
JAGab72262; 8606104633
Excessive static data for arenas and arena mutexes.
JAGaa14937; 8606114983
Inadequate statistics reporting to meet partner needs.
JAGaa26400; 8606114986
dirname(3c) causes application death (bus error) due
to segmentation violation.
JAGaa62439; 8606114988
Multithreaded programs deadlocks if they invoke
popen(3C) and fork(2) in different threads.
JAGab77826; SR 8606107568
regcmp(3C) call might fail on 64-bit on if the regular
expression is huge.
JAGab71463; SR 8606104124
VxFS ACL fails with large UID's/GID's (>=0x80000).
Once the file has one such entry in its ACL list, any
subsequent acl operations return "Invalid Argument"
error:
[ aldan:/mnt ] (90) touch TEST
[ aldan:/mnt ] (91) setacl -m user:12345678:r-- TEST
[ aldan:/mnt ] (92) getacl TEST
acl failed for file "TEST", Invalid argument
JAGab76091 JAGab76238; SR 8606106738; SR 8606106818
Core dump may occur when domain-name is not found in
the search list specified.
JAGab72180; SR 8606114994
A large number of threaded applications invoking
getXXbyYY calls on a MT system and running simultaneously
may hang, when the file table overflows.
JAGab82346; SR 8606109646
rpc calls invoking dns backend will not function
properly with the new dns backend library libnss_dns.1.
As a result applications using rpc like CDE and NFS will
not function properly .
JAGab68997; SR 8606115002
The host address type in the returned hostent structure
was not being set to correct value when IP address was
being passed to gethostbyname call.
JAGab71977; SR 8606115130
TZ env var (STD#DST,date1,date2) ignores DST if date1
greater than date2
JAGab75719; SR 8606106516
Under some offset, destination string lengths, and counts
beyond the terminating null in the source string strncat
can move fewer than the required number of bytes.
JAGab84233; SR 8606112024
PHCO_20369:
This is an SP patch version of PHCO_20555.
PHCO_19691:
strptime()/mktime() dumps core for the years
beyond 2038 when compiled with -z(do not bind
anything to address zero) option.
JAGab72590; SR 8606104837
1. ctype(3C) routines are too slow and the macros
have too many instructions because they contain
function calls.
2. The performance of singlebyte applications using
the ctype routines needlessly degrades in multibyte
locales.
3. strcasecmp(3C) and strncasecmp(3C) are too slow
compared to other vendors because they rely on
_tolower(3C) which is a macro mapped to a function
call.
JAGaa43050 JAGaa05164; SR 8606106824; SR 5003416776
mktime() does not seem to adjust for change in TZ
variable.
JAGaa44810; SR 5003444117
strptime(3C) returned NULL when processing the date
string generated by the command "date +%x" for locales
zh_TW.ccdc and zh_TW.big5.
JAGaa08262 JAGaa47278; SR 8606106825 ; SR 8606106827
When calling strncmp with one valid string pointer,
a null pointer and a length of zero strncmp will return
the first charater or the negative of the first
character of the valid string instead of an expected zero.
SR 5003463463
If the comparison character for memchr is a negative
integer memchr will not find the match.
JAGaa93243; SR 1653294272
Strrstr(s1, s2) sometimes claims that a match is found
when actually there is no match. Consider an example.
s0 = "ABCDEFG";
s1 = s0;
s1 ++; /* s1 points to "BCDEFG" */
s2 = "ABCDEFG".
Now strrstr(s1, s2) returns "ABCDEFG", which means
that a match is found. It should have returned NULL.
JAGaa41142; SR 5003436923
When attempting to assemble using a 9.X assembler the
assembler complains about unknown syntax.
JAGaa62460
64-bit regexec(3C) returns with large positive numbers
assigned to pmatch[i].rm_eo, and may cause applications
coredump.
JAGaa46130
An internationalized application leaks memory at every
setlocale() call to change its locale environment.
JAGaa06047
An internationalized application which frequently calls
setlocale() to change its locale environment encounters
a serious performance problem.
JAGaa08086; SR 4701391243
A multi-threaded internationalized application fails
in setlocale() for the restore operation using the buffer
returned by the previous call to setlocale().
JAGaa32025
memcmp() could return an incorrect result if the third
parameter to memcmp was a negative value.
JAGaa24067
VxVM pathnames not recognized by blocktochar()
JAGab69351; SR 8606103064
Linking with libc.sl can produce a slower running
application than linking with libc.a.
JAGab15584 JAGab16669
strtod("NaN",ptr) on HPUX 11.0 returns a ptr past the '\0'
JAGaa05185; SR 4701389726
glob(3C) cannot handle more than one trailing
'/' in a path string.
JAGaa94846; SR 1653297432
strxfrm does not work correctly for positional
forward and backward single as well as multi
byte locales.
JAGaa95471
The getcwd() API is slow and accesses remote
filesystems unnecessarily when there is a mount
point on the path to the current directory.
JAGaa01123, JAGaa40237
The contents of the struct utmp is NULL when end
of file /etc/utmp is reached, but the struct utmp
should contain the last utmp entry.
JAGaa05209
NaN and Infinity were printed incorrectly in case of
long double.
JAGaa86217
Poor multithreaded malloc performance, primarily
caused by mutex contention and mutex locking overhead.
Incorrect malloc statistics. Inadequate statistics
reporting capability. 64-bit multiarena malloc aborts
when user specifies _M_ARENA_OPTS.
JAGaa40240, JAGaa01969, JAGab19981, JAGab16523, JAGab43915
JAGaa26400, JAGab43837, JAGab53676, JAGab19980
SR 5003436451; SR 1653255513;
regexec() finds for "." in empty string "" with
locales other than C.
JAGaa53114; SR 4701413906
PHCO_19491:
Pre-enable additional filesystem type recognition.
JAGab68821; SR 8606102818
PHCO_19391:
Multithreaded applications hangs if one of the threads
vforks and does an exec(2) call (except the execve(2)
call).
Memory leak in applications using vfork and exec(2)
calls except execve(2) calls.
JAGaa55615
version 4, JFS ACL support is enabled within VxFS.
The libc patch is to create new APIs for JFS ACL,
and update existing ACL related interfaces in libc
aware of the new acl type, JFS ACL.
JAGaa95281; SR 4701420935
JFS 3.3 release introduces a new VxFS disk layout,
version 4. The new disk layout is used to support
JFS ACL, JFS Clone FS feature, and has an enhanced
fsadm shrink capability. The libc patch is to make
JFS related interfaces in libc aware of the new disk
layout.
JAGaa95281; SR 4701420935
PHCO_19090:
If atoi() is passed a string containing a character with
code value greater than 127 (\x7f), the wrong answer may
be returned using a 32-bit libc or there may be a
coredump with a 64-bit libc.
JAGab25446, JAGaa05164; SR 8606100279
PHCO_18227:
When a process is in the kernel and receives a self-sent
SIGABRT signal via abort(3C), the contents of the callee
save registers are undefined. This causes DDE unable to
unwind the core file generated by abort(3C).
JAGaa43927; SR 5003443143
strftime(3C) returns week number 52 for 12/27/1999-
12/31/1999 and 53 for 1/1/2000-1/2/2000.
JAGaa46298
malloc is slow for multi-threaded applications.
JAGaa32680
Strcoll performance very bad compared to that of 9.x.
JAGaa00524; SR 1653214346
Strcoll failure. Single byte locales did not collate
properly when an old version of single byte locale (using
multi-byte routines for single byte locales) is used with
new version of libc (where single byte routines are used
for single byte locales). The original change was made in
10.10.
JAGaa18768, JAGaa18769
libcres--new library : Applications that have statically
linked with libc can experince core dumps if libc.sl
changes internal call graphs.
JAGaa43395
mkfs(hfs) can't handle VxVM volume pathnames
JAGaa42843
memchr() perf improvement: memchr() does not perform
well when static branch prediction is enabled. memchr()
causes stack overflow problems for large values of
length. memchr does 64 bit compare operations on
32 bit operands.
JAGaa13890, JAGaa41248
mktime(3C) sets tm_isdst to 0 when daylight savings
is in effect for dates past Tuesday January 19 03:14:07
UTC 2038. Since strptime(3C) obtains this value from
mktime(), it also returns the 0 for tm_isdst when daylight
savings is in effect for those dates.
JAGaa16206, SR 4701405688, JAGaa23230 SR 4701405696,
JAGaa23233 SR 4701405720
strptime() does not check for dates not within the
supported range of Friday December 13 20:45:52 UTC 1901
and Friday December 31 23:59:59 UTC 9999.
JAGaa23231 SR 4701405704, JAGaa23232 SR 4701405712
In 64-bit HP-UX, getdate(3C) does not check for
dates not within the supported range of Friday December
13 20:45:52 UTC 1901 and Friday December 31 23:59:59 UTC
9999.
JAGaa26931 SR 4701409581
PHCO_18103:
64-bit applications may dump core when attempting to
use getcwd(3C).
JAGaa95447
PHCO_17601:
Excessive locking of /etc/mnttab in the getmntent(3X)
family of APIs can cause a deadlock.
JAGaa01122, JAGaa01628
On a 64bit system strlen() returns incorrect values
when the lower 32 bits of address are a zero.
JAGaa93445; SR 4701418293
For a week which contains days in the previous year
and the new year, strftime(3C) with %V returns week
number 53 for those days in the new year if they are
less than 4 days in the new year in that week,
regardless of whether the last week of the previous
year is 52 or 53; otherwise, it returns 1. It returns
either 52 or 53 for those days in the previous year.
This result in two different week numbers for days in
the same week for certain years.
JAGaa62691
An internationalized application leaks memory at
every setlocale() call to change the locale environment
(The query operation doesn't leak the memory).
JAGaa92941; SR 1653294694
getpwnam() returns wrong values sometimes, making
the system unreliable.
JAGaa46458, JAGaa72866; SR 1653284414; SR 1653287904
getcwd does not handle Loop Back File Systems (LOFS)
correctly.
JAGaa86037; SR 4701416800
PHCO_16629:
memcmp(3C) returns incorrect values when compiled
with +DA2.0N. memcmp, memchr, strncat do 64 bit
compare opearations on 32 bit operands.
JAGaa41144, JAGaa41248; SR 5003438507; JAGaa41796
malloc performance is very slow.
JAGaa17260
On some configurations 64-bit applications using a
long double get incorrect results.
JAGaa35268, JAGaa32697, JAGaa40380
Performance of getcwd() may degrade in certain cases.
JAGaa40211
SHLIB_PATH is enabled in the 64-bit flavor of libc.
JAGaa22065
setjmp/longjmp calls cause SIGBUS/SIGSEGV if application
is linked with CXperf tool.
JAGaa32076
Tuned, threaded applications using the small block
allocator use more memory than before.
JAGaa32072
PHCO_16130:
strcoll and wscoll of strings with collating elements
fail.
JAGaa18768, JAGaa18769
(1) strptime(3C) does not support dates beyond January
19 UTC 2038 in 32-bit HP-UX. (2) strptime() does not
fill in tm_wday, tm_mon and tm_mday when supplied both
the year and day of the year. (3) strptime() does not
treat invalid input dates and inconsistent input as
errors. (4) strptime() does not handle %E correctly
in the C locale. (5) strptime() returns incorrect
value for tm_yday and tm_wday if tm_sec and/or tm_min
are initialized to -1 when the %j conversion
specification is used.
JAGaa06544; SR 5003416719
strptime() treats Feb 29 2000 and March 1 2000 as
the same day if the %A (or %a) and %U conversion
specifications are used. JAGaa13581
JAGaa13581; SR 1653269738
getcwd(3C) fails with ENOENT if the root file system
is a loopback file system (LOFS) after a chroot.
JAGaa11165, JAGaa01441, JAGaa05219, JAGaa06021
SR#4701382374; SR 4701394395 ; SR 4701389916
SR 4701390120
getenv runs very slow for multi-byte languages JAGaa05075
SR#1653259333
The getdate() function does not parse the template file
correctly when the %r field descriptor is used in at least
one of the templates. This leads to the situation that a
non-zero value for getdate_err is returned even when the
template file contains a matching template.
In addition, getdate() does not correctly handle the case
where %I is used in a template but %p is not. JAGaa00429,
JAGaa10165, JAGaa10166, JAGaa10167, JAGaa10168,JAGaa05222,
JAGaa10164, JAGaa10163, JAGaa08067, JAGaa10158,JAGaa12392
memcmp( ) does not perform well when static branch
prediction is enabled. JAGaa06535
PHCO_15768:
When LANG=japanese, the sed command, s/$/x/, would not
add the character to the end of lines. JAGaa01206
SR 5003396234
Commands dump core if LC_COLLATE=nonC and LC_CTYPE=C.
JAGaa01685; SR 4701385336
__strnlen() API in 64-bit mode returns incorrect value
of the length of string. The __strnlen() API returns
correct length of string in 32-bit mode, though.
JAGaa01674
JAGaa01271: syslog()
Calling openlog() with a very long ident string causes
syslog() to dump core or create unexpected/undefined
results.
Multi-threaded applications using usleep(3C) hang.
JAGaa01457
When Null pointer was used as argument for fputs and
puts, the behavior is inconsistent between pre-10.20
and 10.20 onward releases. JAGaa01279 JAGaa01511
JAGaa01513 JAGaa01515
syscall() API doesn't handle 5th and 8th arguments
correctly. These parameter values are not handled and
hence return value from syscall() API would not be
correct. JAGaa04782
setjmp() function coredumps with Memory fault if the
program is compiled with 64-bit mode (+DA2.0W) and -z
compiler option along with patch PHCO_14102.
JAGaa01982; SR 1653257121
PHCO_14704:
Libc does not compile with the changes made in ftw.h to
provide Large Files support for C++ due to the use of
"struct stat64" in the internal 64-bit ftw interfaces.
JAGaa01664
The API sigspace() causes the calling process to hangup
if called after another call to this function; sigspace()
also causes the calling process to terminate if called
by more than one thread within a process. JAGaa01033
JAGaa01062
The API execvp(const char *file, char *const args[])
fails (returns -1) with errno set to E2BIG if the
following conditions are met: (1) the 'file' is a
shell script that doesn't specify the interpreter
being used. (e.g., #!/usr/bin/sh); (2) the number
of arguments contained in arguments (args[]) is
greater than 254. JAGaa00583
Enhancement request for providing a new threads API
__thread_detach(). JAGaa01380
Customers using their own versions of malloc() and free()
would notice free() being called twice on a same block
while using the glob() libc API. JAGaa01494
This is an enhancement request to provide jmp_buf pointer
in the hook functions of HP CXDL Development Tool. These
hooks are called from setjmp() and longjmp() APIs while
applications are linked with HP CXDL Development Tool.
JAGaa01603
Inconsistent behavior from pre 10.20 systems and 10.20
onwards in memccpy() API. JAGaa01280.
The API regcomp() dumped core, instead of returning
error, when dealing with some non-recognizable expression.
JAGaa01396, JAGaa01496, JAGaa01497
strptime(3C) does not calculate the week number correctly
when the first day of the year is a Sunday (for %U and %W)
or a Monday (for %W). JAGaa00976 1653231456
When users with expired passwords try to log in on the
console, they get usage message from the passwd command:
"usage: passwd [-F file] [name]". DTS JAGaa00533, SR
5003380394.
Threaded applications calling the gets(3S) API may hang
after doing another i/o operation on stdin. DTS JAGaa01148
SR 5003394833.
Code cleanup done in getcwd.c. User behavior unchanged.
JAGaa01101
PHCO_14102:
Applications that fork & implement their own malloc will
not compile. JAGaa01398; SR 4701382259
PXperf performance tool doesn't collect correct statistics
across setjmp/longjmp() family of calls. JAGaa01399.
When the length of the environment variable LANG is longer
than 1024 (MAXPATHLEN), catopen(3C) in /usr/sbin/lanadmin
caused coredump. JAGaa01290.
Calling perror(string) with the length of the string and the
message larger than 1024 will cause coredump. DTS #
JAGaa01178, JAGaa01166.
Signal mask is not restored after calling free when
mallopt(M_BLOCK,0) has been set. Only happens on multiple
calls to free for the same pointer. DTS JAGaa00773,
JAGaa00489, DSDe424072; SR 1653228304 1653119560 5003156760
JAGaa00476
If malloc() is requested for an impossibly large size, for
example 2 GB, when large malloc has been enabled, this
request fails when malloc() returns NULL and sets errno to
ENOMEM, as it should. However subsequent calls to malloc()
with smaller reasonable sizes should be successful, yet
they fail when malloc() returns NULL and sets errno to
ENOMEM. DTS# JAGaa01179.
In the event that times(2) fails in a multi-threaded
application, clock(3C) does not release the mutex. This
will cause the next thread that invokes clock() to wait
forever for the mutex, in effect, causing the application
to loop forever. DTS # JAGaa00967.
NIS map transfer fails due to transfer timeout on slave
as a direct result of an inefficient method of scanning a
sparse DBM database. DTS # JAGaa01111, JAGaa01150; SR #
5003392126.
PHCO_13412:
64-bit Fortran 90 gets unexpected signal and the floating
point exception handling fails. DTS CLLbs12814 CLLbs12830,
SR 4701376756; JAGab68498
PHCO_13283:
The HP CXDL Development Tools don't collect correct
performance statistics across setjmp/longjmp() family of
calls. DTS JAGaa00559, SR 4701374496; JAGaa01168.
The wcswidth(3c) API depends on methods/locales to
return a value 0 for an empty wide string. Sometimes
a locale would return a value other than 0 for an empty
wide string. DTS JAGaa00448, SR 4701374470; JAGaa01167
Core dump in certain corner cases. DTS JAGaa01047, SR
4701374504; JAGaa01169
Defect Description:
PHCO_27608:
Libc malloc(3C) family of API's hang if the complete
heap of the process is exhausted and application calls
free()/realloc().This happens because of improper
handling of resources by malloc(3C) itself.
Resolution:
The hang problem in free()/realloc()/malloc() is
resolved by releasing the resource held by thread.
JAGae26049; SR 8606261730
PHCO_25976:
When the domain name is set to null and when the
NSS (Name Service Switch) configuration is "files nis"
for password database, then the getpwent(3C) API dumps
core with the SIGBUS error. In the switch code, the
destructor for the same files backend is called
second time.
Resolution:
The code flow is changed in such a way that the destructor
for the same files backend will not be called more than
once.
JAGae00927; SR 8606231691
When gethostbyname(3N) is called with an IP address as the
argument in a multi-threaded environment, the static
global variables may be corrupted as they were not
protected for threads.
Resolution:
The global variables are now protected for threads by
defining them locally to the function where they are used.
JAGae19108; SR 8606254777
Duplicate entries problem in the utmpx file,would result
in more than one entry for the same pts/pty/tty. This
leads to a situation wherein only one of the entries in
the /etc/utmpx file is correct and signifying the current
session of the user and the rest of the entries being
incorrect. They correspond to processes that no-longer
exist but still are marked as user processes. logname(1)
command and getlogin(3C) API would report incorrect
username in this case.
Resolution:
The fix takes into account the current session for a
particular terminal. It compares the session id of the
calling process and the session id of the ut_pid entry in
the /etc/utmpx file to get the correct entry which is
the entry corresponding to the current user's session.
JAGae07413; SR 8606238389
In strtod(3C),if the first argument is "infinity", it is
returning next to next character after "infinity". But it
is supposed to return next character after "infinity".
Resolution:
strtod(3C) is modified in such a way that, if the first
argument is "infinity", then it will return next
character after "infinity".
JAGae26691; SR 8606262356
If an application calls any of the APIs getpwnam(3C),
getpwuid(3C), getgrgid(3C), or getgrnam(3C) and closes
all open files prior to or after forking a new process,
the above mentioned APIs will show undefined behavior
in the child context.
Resolution:
Libc source has been modified so that the APIs
getpwnam(3C), getpwuid(3C), getgrgid(3C) and getgrnam(3C)
will not use the cached file descriptor in the child
context after fork, if it is already closed and reopened.
JAGae21220; SR 8606256907
The system commands like telnetd(1M), rlogind(1M) and
login(1M) use the getut(3C) and getutx(3C) APIs while
updating or adding the entry to /etc/utmp and /etc/utmpx
files. The APIs getut(3C) and getutx(3C) searches the
files linearly for the given entry. Whenever there are
large number of entries (for example: more than 2000 )
in the /etc/utmp and /etc/utmpx files, searching for a
particular entry is taking long time(several minutes)
and this leads to poor response of the system whenever
large number of login or logout happens simultaneously.
Resolution:
This is a fix to provide pre-enablement for a
future release of login(1M), telnetd(1M) and rlogind(1M).
This solution is applicable only for above mentioned
system applications. The APIs getutid(3C), getutxid(3C),
pututline(3C), pututxline(3C), getutxline(3C) and
getutline(3C) were modified to avoid linear searching
of the files /etc/utmp and /etc/utmpx while updating or
adding the given entry in the files.This will lead to
better performance whenever large number (for example:
more than 2000) of login or logout sessions happen
simultaneously.This solution will have no impact on
the current functionality of login(1M) telnetd(1M) and
rlogind(1M) and other applications on the system.
JAGac42568; SR 8606125689
Application crashes when threads are created with
non default stack size
Resolution:
Provided a wrapper for creation of thread with
non-default stacksize
JAGae10553; SR 8606243323
PHCO_25707:
There is a null pointer dereference in localtime() that
causes core dump when the application is built with -z and
the environment variable TZ used is not in the file
/usr/lib/tztab or the environment variable TZ is the last
entry in the file.
Resolution:
The pointer is checked for null before de-referencing.
JAGad94442; SR 8606225355
stdio interfaces acquire mutexes to enable multi thread
safety of the interfaces. The registered atfork-handler
also tries to acquire the same mutexes which causes the
deadlock. The scenario was that the thread performing the
blocking read is blocked on a pipe and waiting for the child
to spawn and write on the pipe. As the child will not be
spawned until the thread performing the fork() is able to
acquire the lock, it is a deadlock situation.
Resolution:
The locking of the stdio mutex in atfork-handler has been
removed. With this fix, deadlock in parent will not occur
as reported in the defect.
JAGad68247; SR 8606199060
PHCO_24723:
mktime takes the timezone specifications from /usr/lib/tztab
file. Incase the application does a rapid switch between 2
invalid time zones then for each switch the tztab file is
accessed and searched for the required time zone. Hence for
each switch the file is read completely. This degrades the
performance of mktime.
Resolution:
The /usr/lib/tztab file is cached in memory local to the
process, the first time mktime is called, and each
subsequent call to mktime makes use of this cached data.
This approach reduces the number of disk read operations.
JAGad75245; SR 8606206070
delmntent libc routine deletes the entire contents if mntent
structure obtained from the call to getmntent was passed to
delmntent.
Resolution:
The defect is due to the returning of same global buffer by
getmntent call to an application and the same global buffer
being used in the delmntent libc call. The code has been
fixed to address the problem.
JAGad81071; SR 8606211883
regexec() does not handle multibyte characters correctly.
where the second byte of a multibyte SJIS character is
interpreted as stand alone single byte character.
Resolution:
For matching a pattern containing .* , .+ , regexec
traverses the entire length of the string and then
backtracks to find out whether it can match the remaining
part of the pattern. The backtracking logic currently
doesn't take the multi-byte scenario into consideration and
goes back byte by byte. In the case of a multi-byte
character with a valid character as a second byte, a match
is found for the second byte even though it is not a
stand-alone character and just forms part of a multi-byte
character. Now the code has been changed to take care of
multi-byte back tracking.
JAGad74356; SR 8606205180
An application using the directory(3C) API's in
multithreaded environment got into mutex contention problem,
which resulted in 100% usage of the CPU resource time.
Resolution :
opendir and closedir API have been enhanced to reduce the
mutex contention.
JAGad82310; SR 8606213123
The HP-UX libc memory allocator is slow for C++ applications
which frquently allocate and deallocate small blocks, as it
uses the cartesian tree to maintain the free block list.
Resolution:
mallopt(3C) is enhanced to provide a new commond M_SBA_ON
which will be used by C++ initialization library to
configure predefined SBA parameters.
JAGad74141,JAGad84551; SR 8606204965, 8606215364
memchr can read past the area passed to it causing core
dumps.
Resolution:
Code change is done in memchr to avoid reading beyond the
memory passed to it.
JAGad63604; SR 8606194394
memchr returns NULL even when the character searched for is
present in the string passed to it when the count is -ve.
Resolution:
Logic is changed in the memchr to handle the -ve count.
JAGad86533 ; SR 8606217381
When putw() fails, it is supposed to set the error flag for
the file stream, set the errno describing the error occurred
and return EOF. Only the errno was being set but error flag
of the file stream wasn't being updated due to which EOF was
not being returned.
Resolution:
Change has been made so that, in case no write permissions
are found for the file stream, the errno is set and EOF and
the file stream's error flag is set.
JAGad72144; SR 8606202970
There was a missed condition wherein a file stream which has
been opened in write-only mode, an immediate fread on the
stream failed but if the fread() followed after a fwrite()
didn't report an error.
Resolution:
Explicit condition check on mode of operation of file stream
solves the problem.
JAGad72400; SR 8606203226
rcmd is exiting with long hostname. The hostname with
length greater than the buffer size, is the cause for
exiting.
Resolution:
Length of input string will be checked before it is copied
on to the buffer.
JAGaa27187
check for long user names missing in code.
Resolution:
The program is modified to check if the length of the string
passed, is lesser than the buffer length before copying
string on to the buffer
JAGad27794; SR 8606158464
res_query() dumps core when called through a large number of
threads simultaneously from a single process as the socket
descriptor may cross 2048 which is the current limit.
Resolution:
The code has been modified to handle any number of threads
(limited by system resources only) as the limit on socket
descriptor is removed.
JAGad81970; SR 8606212783
PHCO_24148:
The getXXent call and endXXent functions call shl_unload()
function to unload the shared backend library when the
number of references to the backend instance structure is
zero. However, the library call shl_unload() on PA32
machine unloads the shared library regardless of whether
there are other references to it through other load
invocations. This causes the subsequent shl_unload call
fail with signal 11.
Resolution:
Removed the shl_unload call for PA32 architecture in the
SO_per_src_delete function.
JAGad65825; SR 8606196622
The defect was due to blocking the signals after locking the
malloc mutexes in the case of multi threaded malloc. When
malloc/calloc/valloc/realloc is called in signal handler and
also the main thread of execution and there are frequent
signals to application. The application becoming busy in
locking and unlocking the malloc mutexes resulting into
application hang situation.
Resolution:
Signals blocking is done before locking the mutexes. Which
avoids the too many mutex locks and unlocks.
JAGad55731; 8606186527
mallinfo(3C) doesn't give correct memory statistics if the
application is multithreaded and uses multiple arenas. The
problem was introduced during multi arena enhancement. The
way mallinfo() designed works fine only for single arena,
but the problem starts when there are 2 or more arenas and
there is a overlapping brk value.
When multiple threads call malloc(3C) to allocate space,
each will be assigned an arena. Each arena will maintain
the start and end point of that arena. The arena_start
represents the starting heap address for this thread and the
end_arena represents the ending address. Assume 2 threads
are say THREAD1 and THREAD2 running in parallel. THREAD1
calls malloc(), malloc stores the the arena_start1(current
brk value say 0x1000 ) and extends the brk value to
predefined size and sets the end_arena1(0x4000), similarly
THREAD2(arena_start 0x4000, arena_end 0x8000). If THREAD1
again calls malloc() and there is no pre-allocated space in
the arena, the brk value is increased and arena_end will be
set( 0x12000).
The mallinfo() will collect the size by visiting each arena
starting from arena_start till arena_end of that arena. In
the above case arena_start and arena_end of THREAD1 is
0x1000 and 0x12000 respectively, for THREAD2 arena_start is
0x4000 and arena_end is 0x8000 respectively. While counting
the size, arena for THREAD2 will be counted 2 times, once
with arena1 and once with arena2. Hence the problem. In
single arena implementation this problem will not be
revealed.
Double counting is happening because we will modify the
dummy header when AClastbrk != _curbrk (AClastbrk <
_curbrk). The dummy header which had SIZE=0 and USED set,
will be set with the difference of _curbrk and AClastbrk in
the function grow_arena(). If the AClastbrk of one thread
is not equal to the _curbrk, the possibility is that either
user application called brk/sbrk or the function grow_arena
is called by some other thread. If the _curbrk value is
changed from some other thread by calling grow_arena() then
the other thread treats this as the user allocation and the
dummy header is modified appropriately and fixes the
arenaend for this thread.
The problem will be there if there is a overlap between the
brk values of the different arenas. So in the current
implementation USER_ID is used when
O The application directly calls brk/sbrk
O The other arena calls brk/sbrk (in grow_arena()
i.e. AClastbrk != _curbrk)
The problem is because of setting USER_ID when the other
arena calls brk/sbrk (in grow_arena() i.e. AClastbrk !=
_curbrk).
Resolution:
The resolution is basically to avoid the use of USER_ID when
the other arena calls brk/sbrk (in grow_arena() i.e.
AClastbrk != _curbrk). A new memory block identifier
ARENA_ID is defined in malloc.c as
#define ARENA_ID 0x13
The ARENA_ID is used to mark that the memory block is used
and it is used by some arena. The used memory block will be
marked with ARENA_ID under the circumstance mentioned below.
When a block of memory is used by some other arena and the
last brk value maintained in the that arena is not equal to
the _curbrk. While counting memory usage statistics in
mallinfo(), the memory block with ARENA_ID as the id we will
skip because it is used by some other arena and will be
taken into account under that arena.
The two global variables
char *_node_curbrk
char *_common_curbrk are also defined in malloc.c.
node_curbrk: The variable _node_curbrk is used to identify
if there are 2 successive call to the function node_alloc()
from different arena. The check is required because when
space is allocated for nodes, no space will be allocated for
the dummy header.
common_curbrk: This variable is analogous to _curbrk.
_curbrk keeps track process wide brk value, but
_common_curbrk is to keep track the brk activity within
malloc module. This variable is used to decide whether the
brk value is changed by some other arena OR application has
called brk(2)/sbrk(2) system call. If the _common_curbrk is
not equal to _curbrk means that the application has called
the brk(2)/sbrk(2).
JAGad34660; 8606165366
ptsname corrupts heap SIGBUS may result. It is a bug in
ptname() function.When the application is linked with
libpthreads,it dumps core.
Resolution:
The cause of this problem is instead of passing the sizeof
bytes allocated by malloc to the GET_TSS() function, the
sizeof the character pointer returned by malloc is passed as
an argument. So,it is always taking sizeof the character
pointer which is less than the number of bytes allocated by
malloc. ptsname() is modified accordingly to address this
problem.
JAGad46861; 8606177629
When the variable TZ is not set in the environment, in HP-UX
it defaults to EST5EDT which is the east coast time in US.
This poses problem in the environment of the processes that
(a) are started by init(1m)
(b) clear their environment (e.g. login (1), sendmail(1m) )
The hard coded value is inappropriate for any timezone other
than east coast of US and the difference is difficult to
track for countries like Australia which frequently update
their daylight timing rules.
Resolution:
When the environment variable TZ is not set, tzset() checks
the default file /etc/default/tz for the timezone value and
sets timezone values based on that.
The file /etc/default/tz contains the timezone value set by
tzset() when the environment variable TZ is not set. The
format for the file is same as TZ format without the prefix
"TZ=". Please check environ(5) for TZ format.
The order of TZ setting is as follows.
1) if the environment variable TZ is present, it takes
precedence.
2) if TZ is not present then the value contained in
/etc/default/tz is used for the default.
3) if /etc/default/tz is not set then the default value is
equivalent to EST5EDT (Eastern Standard Time) of US.
(Install the Patch PHCO_23652 to get the sample
/etc/default/tz file. Please read "Other Dependencies" field
for more information on PHCO_23652 patch)
JAGab20870
valloc() fails to allocate the memory in multi threaded
application when there is space available in other arenas.
The problem is because in multithreaded application if the
space on heap is exhausted and no space in the particular
thread's arena, valloc is returning NULL. But there could
be some space available in other arenas and that can be used
under this arena.
Resolution:
The allocation alogorithm for valloc() is modified, to try
allocation of space from other arenas when there is no space
left on the heap.
JAGad47526; 8606178299
Initialized TLS support in libc for 64 bit non threaded
applications.
Resolution:
The initialization routine of Libc has changed to support
initialized TLS variables in a PA64 non threaded
applications. Both the archived and shared version of the
libraries have this enhancement.
To get the complete functionality of ITLS (Initilized thread
local storage) the following patches has to be installed.
PHSS_23440 - linker core
PHSS_23785 - linker ISU
PHCO_23792 - libpthread
PHSS_23953 - Fortran compiler
Currently this feature is available with Fortran compiler
only.No changes are required to be done in libc when this
feature is made available for any other compilers.
JAGad49168; 8606179946
fstyp command calls statvfsdev on VxFS version 4 disk layout
returns "unknown_fstyp". It fails on accessing initial
inode list extents block address which exceeds 32 bit
addressing. lseek64 should be used instead of lseek in
__vx_fs_lseek.
Now the call to lseek is replaced with lseek64 by using a
compilation flag _FILE_OFFSET_BITS=64 in the makefile.
JAGad57721; 8606188513
When the APIs getprpwnam(), getgrnam(), getnetbyname(), and
getservbyname() are configured with the /etc/nsswitch.conf
file to search sources that do not support these calls, the
Name Server Switch engine code unloads the sources and
returns NSS_NOTFOUND. The source "nis" doesn't support the
trusted system call getprpwnam(). The source "dns" is only
valid for the "hosts" database. Thus, subsequent API
getXXXbyYYY calls that try to search sources that have been
unloaded end up accessing invalid locations, resulting in a
SIGSEGV core dump.
Resolution:
If a source doesn't support an API getXXXbyYYY call, don't
unload the source. Just have the Name Server Switch engine
code return NSS_UNAVAIL.
JAGad41604; 8606172344
The strcasecmp() and strncasecmp() functions behave
incorrectly when presented with strings containing bytes in
the range 128-255. The incorrect behavior can result either
in a core dump or an incorrect comparison value, depending
on the data.
Resolution:
Cast chars to (unsigned char) before using as index in
_tolower().
JAGad66064; 8606196866
PHCO_23770:
When a C application uses C++ plugins and calls pthread/cma
calls in static constructor/destroctor, it was leading to
destructor being called twice. This was happening because
the C++ runtime initialization routine was invoked at a
point when the pthread library initialization would not have
been complete . During this time, constructor was invoking
pthread calls . This might have lead to destruction of the
shared data (static/global) in the libCsup.
Resolution:
Changes are made to libc so that C++ runtime initialization
routine is invoked only after the completion of pthread
library initialization.
JAGad55189; SR 8606185984
PHCO_22923:
On HP-UX if a nonthreaded application links to a
thread-safed library the link will fail due to unresolved
pthread symbols.To resolve these symbols, it is necessary to
link the nonthreaded application to the threads library
libpthread.But linking to that library makes the application
threaded even if it creates no threads.Providing POSIX 1c
thread "stubs" in HP-UX C language library have two direct
effects for nonthreaded applications. a) POSIX 1c threads
symbols are resolved if a nonthreaded application links to a
thread-safed library b)We avoid the overhead of a real
threads library -- especially the overhead associated with
mutexes when the nonthreaded application uses thread stubs
rather than real threads library procedures.
Resolution:
Stubs are provided for all pthread calls only in SHARED LIBC
FLAVORS of the HP-UX C Library. These stubs do not have any
functionality, these are dummy functions returning zero
except pthread_getspecific() family of APIs which has full
functionality implemented in the stubs. Full functionality
is provided in the stub for the following pthread calls
* pthread_key_create()
* pthread_getspecific()
* pthread_setspecific()
* ptherad_key_delete()
* pthread_exit()
call to stub pthread_self() returns 1
call to stub pthread_equal(arg1, arg2) will return
(arg1 == arg2)
Call to the stub pthread_create() and pthread_attr_init()
returns ENOSYS.
All other stub calls returns zero.
There are two special interfaces provided for checking
whether an application is linked to pthread library or not.
a) __is_threadlib_linked()
returns 1 for an applications linked to pthread
library otherwise returns zero.
b) __get_ismt()
returns 1 for applications linked with libcma
returns 2 for applications linked with libpthread
otherwise returns 0
Risks:
------
An application may inadvertantly pick up the stubs when it
intended to use the real pthreads APIs, or it may pick up
the stubs when it needs cma APIs or stubs. These are all
link order problems. An application that needs cma behavior
must link to libcma (or the cma stubs library) and must do
so in a supported link order,
i.e. the link line should be shared only and should
not contain "-lc" before -lcma.
So long as this condition is met, the correct cma functions
will be referenced. Similarly, a multithreaded application
that needs pthread threads library behavior must link to
libpthread and must do so in a supported link order, and
only use shared libc and libpthread.
eg : An applications wants to use pthread stubs then
the link order should be
$ cc test.c -lc -lpthread
An applications wants to use pthread library then the
link order should be
$ cc test.c -lpthread -lc
JAGab69119; SR 8606102984
User cannot use C++ runtime library on 32 bit application
without either using a C++ main program or explicitly
invoking the C++ runtime library's initialization routine,
_main, from the C ( or Fortran ) main program.This problem
is not there for 64-bit PA-RISC applications, or for any
IA-64 applications, since the C++ library's initializer is
run automatically -- either at program startup or when
dynamically loaded.
Resolution:
The definition of the __main_ptr variable is done in
libc_init routine. The same varible is defined as a global
variable in libcsup, which will be initilized to the C++
runtime library initialization routine, _main. Thus, when
libcsup is linked into the program, the variable _main_ptr
will point to _main; otherwise, it will contain 0.
JAGad41440; SR 8606172179
gettimeofday is very slow for certain vendors who use it for
time stamping because it calls a heavy weight system call to
get the current time of the day.
Resolution:
A new API hrtime_t gethrtime(void) has been added to libc.
This API uses fast light weight system call to get the nano
seconds from certain time. It does not give you the current
time of day. hrtime_t is a signed 64 bit number. This API
will only be available if the application is being compiled
in -Ae mode because 64 bit integer number is not available
in -Aa mode.
JAGad44410; SR 8606175166
Global symbols in libc can conflict with one in program
causing SIGBUS. In ptsname.c we have defined two global
symbols alpha and range_spec. They are symbols which are
used only by libc. They should not be visible to customers.
They can conflict with the user defined global symbols.
Resolution:
alpha and range_spec is not used a global symbol in libc
JAGad33756; SR 8606164457
sigwait() does not work as cancellation point if the thread
is cancelled after it enters __sigwait_sys(). When
cancelling a thread that is blocked on sigwait() by means of
pthread_cancel(), the blocked sigwait() returns with EINTR
rather than checking the cancellation point before it
returns and terminate the thread.
Resolution:
When the thread is cancelled, then __sigwait_sys returns
error EINTR and does not set errno. In sigwait we were
checking for errno and setting the cancellation point. Now
that has been modified to check for return value.
JAGad39745; SR 8606170481
memmove() is moving data positioned very close to the
quadrant boundary and it leads to a SIGSEGV. When memmove()
attempts to move >=16 bytes of data, including the last 16
bytes of a quadrant, it fails with a SIGSEGV.
Resolution:
To correct this problem, the initial load word is now done
without modifying the source address. The offsets of the
subsequent loads are now positive from the current pointer.
After all loads are done, we increment the source address by
16.
JAGac87878; SR 8606129543
regcomp(3C) function fails to detect an extended regular
expression match in the input data.For example,If the
pattern is "%|^xyz" and the string is te%st, it gives Found
No Match.
Resoltion:
Defect is fixed by adding an "alternate" flag which is set
when there is an alternate('|') option in the regular
expression.
JAGad31456; SR 8606162140
seekdir core dumps when compiled with -z option
Resolution:
Made changes to check for null pointers before
derefererencing.
JAGac78889: SR 8606128089
Purify reports "Uninitialized Memory reads" in readdir_r
Resolution:
Changes are made to initilize variables
JAGac95112; SR 8606130241
ftw core dumps
Resolution:
Trying to access the freed memory in closedir.c
was causing the core dump. It is fixed now.
JAGad21880; SR 8606152550
When snprintf() is called with arguments like so:
snprintf(buf,0,format,args...);
the buffer pointed to by buf should not be altered
since the maximum number of characters to write
to buf is zero, but the buffer is in fact modified.
Resolution:
Checks for the str_len parameter for zero before doing the
actual processing.
JAGad12471; SR 8606143128
regerror() may dump core for some values of error code
Resolution:
The logic for checking the validity of error code is
changed.
JAGad02475; SR 8606133330
PHCO_22314:
Certain allocation patterns using large malloc cause data
corruption in the last integer of a malloced block. The
root cause is an error in the design of large malloc. The
lowest level allocation function malloc_sbrk() hides from
the caller whether sbrk() or mmap() is used to grow the
arena. However, in general when mmap() is used, allocation
is discontiguous. Depending on whether allocation is
contiguous or discontiguous, two different length values
must be passed to malloc_sbrk() because in the discontiguous
case space must be allocated for a second pair of headers
(the dummy headers that terminate the arena). Since
malloc_sbrk() hides from the caller the fact that sbrk() has
failed over to mmap(), there is no way to know which length
to pass. The implementation always passed the shorter
length, which is correct only for contiguous allocation.
Since the pre-large malloc, sbrk()-only, code detected
discontiguous allocation before calling sbrk() and passed
the correct lengths for each case, when sbrk() was replaced
by malloc_sbrk() the code continued to work for the
sbrk()-based heap. However, when the fail over to mmap()
occurs, and whenever mmap() results in discontiguous
allocation, the code does not detect the discontiguity and
the shorter length is passed to malloc_sbrk(). This means
that the arena end dummy headers are not explicitly
allocated in these cases. Usually, alignment causes the
arena end to be spaced far enough from the user area of the
last block that no data corruption occurs when the headers
are written. However, for certain block sizes and starting
positions this is not true, and the dummy headers overlap
the user area of the last block, resulting in data
corruption.
Resolution:
The ideal fix would involve recoding large malloc so that it
does not have a layer that hides whether sbrk() or mmap() is
being used, and always doing the correct length calculation
for each case. However, the fix we have applied here is
simply to allocate space for the second pair of headers in
every case. This does no harm, because it simply increases
the amount by which the arena is grown, not the sizes of
blocks returned to users. The extra space winds up on the
freelist. Moreover, in most cases the fix does not even
change the amount by which the arena is grown, because the
round-up to the next ALLOCSIZE boundary is the same with or
without the fix. Only for certain sizes of request that are
at or very close to an ALLOCSIZE multiple will the fix make
a difference in the amount by which the arena is grown. In
those cases, the arena will be grown by an additional
ALLOCSIZE. This guarantees that the arena end headers will
not overlap the user area of the last block. It will cause,
in these cases, an extra free block of about ALLOCSIZE to be
added to the free list.
JAGad25621; SR 8606156311
strftime(3C) is a thread safe libc API. In a multithreaded
application when many threads calls this API threads were
blocking on a mutex used to synchronize the threads
execution. The mutex lock holding time by every single
thread was very high because of which, threads were not
executed in parallel.
Resolution:
The previous design of strftime(3C) was using most of global
data, to store the intermediate processed data. To
synchronize the access to this data, in the API strftime(3C)
a mutex was locked on entry into the API and released only
while return. This problem can be observable on V-class
systems. To resolve the mutex lock contention, the global
data is replaced with local data which will be per thread,
and the mutex locking is made very short period of time.
This change promotes the parallel execution of many threads
during the execution of this API.
JAGac86555; SR 8606129009
The problem was traced to a libc code, to acl() stub.
The following check was done:
if ((stat(filep, &statbufp)) != 0)
return (-1);
However, since stat() is a 32 bit function, it would return
EOVERFLOW on files that are 2GB+. It was determined by our
investigation that this call is done only to check that the
file is present. E.g. it was assumed, that an error
returned by stat() would imply a bad filename.
Resolution:
The change was made to remove the stat() check from the
acl() system call. Our investigation has determined, that
the kernel code handles the invalid file names correctly,
and comes back with an appropriate errors when a bad file
name is given. With that in mind the stat() call was
determined to be an unnecessary precaution.
JAGad09568; SR 8606140246
sed(1) hangs in non-C locale for some patterns, awk sub
pattern does not work well under non-C locales. Both these
problems were happening because of underlying problem with
regexec. regexec loops beyond the end of string looking for
match in Non-C Locale.
Resolution:
The problem was traced to libc API regexec. Regexec was
looping and was looking for a match with the pattern when
the end of string was reached. The fix introduces a return
with No match when the end of string is reached.
JAGad05149,JAGac56665; SR 8606136018,8606126100
regcomp(3C) returns bus error in case of lack of memory.
According to the manual pages, regcomp(3C) should return
REG_ESPACE when the system runs out of memory.
Resolution:
In the regular expression sources, in some cases return
value of malloc(3C) was not checked. Without checking the
return value, a member in the structure was assigned with
some value, which is illegal and resulted in bus error. To
fix this problem, the return value from malloc(3C) is
checked. If malloc(3C) returns NULL(No memory), regcomp(3C)
return REG_ESPACE.
JAGad03415; SR 8606134279
When the switch engine fails to get the backend for the last
resource, it does not clean up the resources and free the
contexts. Because of that, the subsequent calls to
getgrent/getpwent have an unexpected value in the context
structure and thus causes the SIGBUS error.
Resolution:
Added the cleanup calls, nss_endent_u() and nss_delete()
in the nss_getent_u() function of the switch engine.
JAGad11220; SR 8606141866
Under certain circumstances strncat can truncate the output
string.
Resolution:
The logic of the strncat function was changed to address
this problem. JAGad16345; SR 8606147002
PHCO_22076:
When a system is disconnected from the network, and the
hostname lookup is configured for dns, it takes a long time
trying to resolve the hostname before it falls back to
files. The customer wants configurable timeouts.
Resolution:
Two new options have been added to make the retrans and
retry values configurable. These 2 values can be set in
resolv.conf as follows.
retrans <value in milli seconds>
retry <value>
Or these values can be set using environment variables
also.
RES_RETRANS
RES_RETRY
Two new apis are provided to provide programmatic access
to resolver(3N) retransmissions or timeouts:
get_resfield (int field, void *value, int len);
set_resfield (int field, void *value);
field - is either RES_RETRANS or RES_RETRY.
value - is the value to be set or obtained.
len - is the sizeof(value).
The order of precedence is as follows.
1. environment variable
2. resolv.conf
3. API.
JAGaa27175; SR 5003424531
PHCO_20765:
Fork fails to return for threaded applications using
the 11.00 LR libpthread.
Resolution:
A bug in the atfork handler for the dynamically allocated
malloc arena mutexes caused an uninitialized and unallocated
mutex to be locked. The mutexes are no longer dynamically
allocated and the atfork hander has been restored to its
earlier version.
JAGac40398; SR 8606125006
Threaded programs using third-party mallocs abort. The
dynamic allocation of malloc arena mutexes in PHCO_20555
did not check for third party mallocs, which do not allocate
the mutexes.
Resolution:
The malloc arena mutexes are no longer dynamically allocated
and it no longer matters that a third party malloc has not
allocated them.
JAGac40401; SR 8606125009
Threaded applications archive linked to earlier versions of
libc but linked shared to system libraries with dependencies
on shared libc can call the wrong libc mutex initializer,
the one for patch PHCO_20555, which assumes malloc arena
mutexes are allocated dynamically. However the older libc
that was archive linked to these applications assumes the
mutexes are allocated statically. This version mismatch
leads to attempts to lock uninitialized mutexes. This
linkage of archive libc and shared system libraries
dependent on shared libc is unsupported, precisely because
such mismatches can happen.
Resolution:
The 64 malloc arena mutexes have been returned to static
allocation in order to maintain backwards compatibility
with older libcs in (unsupported) archive-shared link
mixtures. The malloc arena contexts are still dynamically
allocated.
JAGac40402; SR 8606125010
Freeing valloced buffers causes sporadic failures in
threaded applications.
Resolution:
A bug introduced in the conversion of valloc for multiple
arenas caused some valloced buffers to be constructed so
that they could not be freed correctly. It has been fixed
in this patch.
JAGac40711; SR 8606125320
In a multi-threaded application, the PHCO_18227 malloc()
created a new arena for each new thread until the configured
number of arenas had been created. This approach led to
excessive memory growth in applications that create threads
sequentially and malloc/free a large amount of memory in
each thread.
Resolution:
The arena assignment algorithm now tracks the active number
of threads in the process and creates new arenas only when
all existing arenas have at least one thread assigned to
them. The new algorithm requires libpthread patch PHCO_19666
to be installed on the system. If PHCO_19666 is not
installed on the system, or if the application is linked
with libpthread.a, then memory growth can be controlled by
setting the maximum number of arenas to be 1.
JAGac40903; SR 8606125513
PHCO_20763:
This is a SP patch version of PHCO_20765.
PHCO_20555:
system() was calling fork() in multi-threaded
applications as a work-around for some locking issues
within dld.sl and libc. The cost of a fork() relative
to the cost of vfork() resulted in slower performance.
The specific issues were related to locking calling
made from the child process created by system() prior
to exec(). The availability of these locks could not
be guaranteed across a vfork() and hence the use of
fork() in the original implementation of system() for
11.00.
Resolution:
system() was changed to use vfork() for all
applications instead of using vfork() only for
non-threaded applications. sigaction() was changed
to not require a lock() around the sigsetreturn()
call when called from the child process created by
system(). This guarantees a lock-free path in the
child created by system(), thus enabling the change
to use vfork().
JAGab78389, JAGab81794; SR 8606108045
In applications using large (shared memory based)
malloc, malloc can return an invalid quad 2 "buffer"
that overlays the stack. This invalid buffer results
from incorrect coalescence of a quad 2 buffer with a
quad 3 mmapped buffer.
Resolution:
The first quad 3 buffer for an arena is never
coalesced to the last quad 2 buffer.
JAGab72262
In threaded applications, malloc statically allocates
64 arena contexts and arena mutexes, regardless of
whether 64 are needed.
Resolution:
Only one arena and one arena mutex are statically
allocated. Others are dynamically allocated from that
one static arena. Only as many arenas and mutexes are
allocated as required.
JAGaa14937
Certain partners require additional undocumented malloc
statistics.
Resolution:
The __mallstat() api has had an additional command added
to read an additional statistic.
JAGaa26400 ; SR 8606114986
If dirname(3c) is given an argument string which begins
on a page boundary, and the prior virtual page is
unreadable for any reason, dirname() causes a segmentation
violation when it tries to look at the last byte of the
previous virtual page.
Resolution:
dirname(3c) checks that it is within the space of the
argument string before looking at a byte of the string.
JAGaa62439
In a multithreaded program, using popen(3C) and fork(2)
calls in different threads can cause a deadlock.
Resolution:
The popen(3C) code has been modified to release the
popen_rmutex lock before calling fork(). This lock is
basically used to update a linked list, namely
popen_table. In order to add the element to this list,
we need to know the pid returned by the fork(2) call.
The algorithm has been changed such that we identify a
free slot in the list(or allocate if none are free),
remove this element from the list, then call fork(2).
After fork(2) returns in the parent, we update the
element, grab the popen_rmutex and update the list
and release popen_rmutex. This avoids the deadlock.
JAGab77826; SR 8606107568
regcmp() stack is not LP64-safe
Resolution:
The data type inconsistency has been fixed by using
the correct data types.
JAGab71463; SR 8606104124
VxFS ACL fails with large UID's/GID's (>=0x80000).
Once the file has one such entry in its ACL list,
any subsequent acl operations return "Invalid Argument"
error:
[ aldan:/mnt ] (90) touch TEST
[ aldan:/mnt ] (91) setacl -m user:12345678:r-- TEST
[ aldan:/mnt ] (92) getacl TEST
acl failed for file "TEST", Invalid argument
The problem was traced to libc code, where the uid in
acl entry is masked by global kernel defenition
IDDONTCARE, which is set to 0x80000. When retrieving
ACL records of a file, the first occurance of such
record is assumed to be the end of list. The lack of
remaining entries then causes EINVAL (Invalid Argument)
error to be returned.
Resolution:
The change has been made to check taclp->a_type
against IDDONTCARE rather then checking field a_id.
This will ensure, that the ACL entries with UID/GID
grater then the value of IDDONTCARE (0x80000) will not
fail. The change will make the code work exactly as a
respective piece in kernel, which has not been causing
any problems as of yet.
JAGab76091 JAGab76238; SR 8606106738
An array that stores the pointers to list of domain names
in the search list is terminated with a NULL pointer.
A pointer dereference was being done and dereference of
a NULL pointer was causing a core dump.
Resolution:
A check is made for the NULL pointer without dereferencing
it.
JAGab72180
res_send call does not close socket descriptors under MT
environment.
Resolution:
The code changes made to frontend was restored to the old
state and also the dns backend was restored to original
code before the IPv6 changes were made.
JAGab82346
The dns backend was modified for IPv6 changes. During
this course, host address type was being passed from the
front end getXXbyYY calls to the backend. RPC calls use
dns backend directly through switch and not through
getXXbyYY frontend calls. As the rpc were not passing
this host address type the backend returns NULL, and the
rpc calls fail.
Resolution:
The code changes made to frontend was restored to the old
state and also the dns backend was restored to original
code before the IPv6 changes were made.
JAGab68997
The host address type in the returned hostent structure
was not being set to correct value when IP address was
being passed to gethostbyname call.
Resolution:
The code changes made to frontend was restored to the
old state and also the dns backend was restored to original
code before the IPv6 changes were made.
JAGab71997
The environ(5) manpage states that the TZ environment
variable can be of the form:
[:]STDoffset[DST[offset][,rule]]
Furthermore, the rule has the form:
date/time,date/time
where the first date/time specifies when to change from
standard to summer time, and the second date/time
specifies when to change from summer to standard time.
This rule works in the northern hemisphere, where the
first date number is less than the second date number.
For example, in Atlanta, Georgia, I might use the
following TZ variable:
export TZ=EST5EDT4,M4.2.0,M10.5.0
Which indicates that I change from standard to summer
time on Sunday, the 2nd week of April, and that I change
from summer back to standard time on the last day of
October.
Notice that in this case 4 < 10, so this works. On the
other hand, in the southern hemisphere, I might use a
TZ variable like the following:
export TZ=SAT3XYZ2,M9.1.0,M1.2.0
This states that we should change from standard to
summer time on Sunday, the first week in September,
and from summer to standard time on Sunday, the second
week of January.This dose not work because 9 > 1 (date1
> date2). The defect here is that the date2 is not
considered as in the next year. It is considered to be
in January of same year of date1 instead of the next
year.
Resolution:
A new condition is added in check for entry into the
DST. This new condition will take care of the
southern hemisphere
JAGab75719; SR 8606106516
When the conditions are where the source offset is
greater than the destination offset and the count is
greater than the terminated source string to concatenate,
strncat can move few than the number of bytes in the
source string.
Resolution:
Corrected faulty strncat logic.
JAGab84233
PHCO_20369:
This is an SP patch version of PHCO_20555.
PHCO_19691:
In 32 bit application, the value of time_t can only be
up to 2038, which we have rules to cover in the file
/usr/lib/tztab. In a 64 bit application, we allow
time_t to bigger than INT_MAX which means larger than
2038. We have a routine to check for this for 64 bit.
The defect here is that, a call to bsearch is made
before this check and that call is assuming that the
input will be less than 2038. But for years beyond
2038 bsearch returns NULL and dereferencing is done
with this NULL pointer and resulting in dumping core
when the application is compiled with -z option.
Resolution:
Check for return value from bsearch,If the return value is
NULL don't dereference.
JAGab72590; SR 8606104837
1. ctype(3C) routines are too slow and the macros
have too many instructions because they contain
function calls.
2. The performance of singlebyte applications using
the ctype routines needlessly degrades in multibyte
locales.
3. strcasecmp(3C) and strncasecmp(3C) are too slow
compared to other vendors because they rely on
_tolower(3C) which is a macro mapped to a function
call.
Resolution:
To allow ctype routines to always perform table lookup,
code populating the tables pointed into by __SB_masks,
__SB_upper, and __SB_lower has been moved from
__ctype_init() in NLSsetup.c to update_locale() in
setlocale.c Now __SB_* pointers are *never* NULL and
are used in all locales by ctype and wctype routines
for characters codes from -1 through 255.
Key to this change is the X/Open and HP specification
that the return value from a ctype API is valid only
for ints from -1 through 255. If the API receives any
other argument value, its behaviour is undefined. This
fact also entailed a change to atol.c (for atoi() and
atol()) to make sure sign extension of a char converted
to an int does not corrupt an argument passed to
isdigit().
Backward compatibility forces us to limit these changes
to internal libc use, since an application built with
the new ctype.h and new libc but running with an older
libc will crash. As a safeguard, all changes to ctype.h
have been placed within #ifdef _SB_TABLE_LOOKUP and
make.defines has been modified to strip those changes
before a ctype.h is built for shipping (in pub_hdr/).
Other files have been changed to ensure the faster
ctype macros are always used in libc.
JAGaa43050 JAGaa05164
mktime() ignores tm_isdst if a previous TZ value had
no dayl. sav. time
Resolution:
When the mktime() is invoked with different TZ
environment variables, a static local buffer "tzbuf" is
used in localtime_r() in ctime.c to store the time zone
name(For ex: PSD8PDT, UTC0 etc..). mktime() looks at
/usr/lib/tztab file for getting the information on day
night savings for the set time zone(Please look at man
pages for tztab). The idea behind using the static buffer
is to avoid reopening of the file /usr/lib/tztab if its
already processed. However, if there is a change in
timezone in between, the file should be reparsed.
The source file ctime.c is modified to check whether
the TZ environment variable has changed and if so,
the TZ variable is copied before further processing
takes place.
JAGaa44810; SR 5003444117
strptime(3C) was unable to process format strings
containing "%EY" or "%EC%Ey" directives and returned
NULL. These directives are used by the era date format
in Chinese locales zh_TW.ccdc and zh_TW.big5. The era
date format (and this defect) are only in the 2 above
locales supplied by HP. The failure is not caused
by a particular date.
Resolution:
A correct algorithm is used to parse the %EY or %EC%Ey
directive.
JAGaa08262 JAGaa47278
When calling strncmp with one valid string pointer,
a null pointer an a length of zero strncmp will return
the first charater or the negative of the first
character of the valid string instead of an expected
zero.
Resolution:
Change the sequence of condition testing in strncmp.
SR 5003463463; JAGab17255
memchr() was not treating the match character as an
unsigned character.
Resolution:
When comparing a negative integer on a short string
memchr did not convert the negative integer to an
unsigned char.
JAGaa93243
Strrstr(s1, s2) sometimes claims that a match is found
when actually there is no match. Consider an example.
s0 = "ABCDEFG";
s1 = s0;
s1 ++; /* s1 points to "BCDEFG" */
s2 = "ABCDEFG".
Now strrstr(s1, s2) returns "ABCDEFG", which means that
a match is found. It should have returned NULL.
The problem is caused by the fact that when characters
in s2 matches characters in s1, the algorithm keeps
going backwards to find if more characters match without
checking if the beginning of s1 is reached.
Resolution:
A check is added to make sure that when the beginning
of s1 is reached, the search stops.
JAGaa41142
Some PA2.0 assembler syntax was used in the 1.1 portion
of the code. The current 11.X assemblers accept this
syntax and emit the correct op codes for 1.1 machines.
Resolution:
changed syntax to conform to PA1.1 syntax.
JAGaa62460
Pointer subtractions involve NULL pointer. In 64-bit,
such subtraction results in overflow or underflow, and
assigning large numbers to pmatch[i].rm_eo.
Resolution:
JAGaa46130
If an internationalized application calls setlocale()
more than once to change its locale environment, it
continuously leaks memory.
Resolution:
Memory needs to be dynamically allocated by setlocale()
to save the locale specific information when changing
the locale environment. The previous setlocale()
implementation didn't free the memory when changing the
locale environment. The new implementation frees the
memory used to save the current locale information and
allocate another memory to save the required locale
information.
JAGaa06047
An internationalized application which frequently calls
setlocale() to change its locale environment will
encounter a serious performance problem.
Resolution:
Separate shared libraries implement the locale specific
information. They are loaded into an application by
setlocale() to change the locale environment. The
previous setlocale() implementation used to load the
required locale shared library and unload the one
currently in use when changin the locale environment.
Loading and unloading locale shared libraries are an
expensive operatoin. The new implementation caches up
to 10 locale shared libraries in the application for
the quick locale switch. And there used to be a number
of str*() and mem*() function calls just to copy and
compare short strings. They have been replaced by
equivalent macro versions to eliminate the function call
overhead.
JAGaa08086
A multi-threaded internationalized application fails in
setlocale() for the restore operation using the buffer
returned by the previous call to setlocale(). This patch
should be installed for such applications.
Resolution:
In a multi-threaded environment, setlocale() and
__setlocale_r(), which exists only for libd4r library,
used to share the implementation in the way that
setlocale() calls __setlocale_r() after protecting itself
against simultaneous calls from more than one thread.
__setlocale_r() erases the previous locale names (set
the first byte to '\0') contained in the passed buffer,
which has caused the problem. The new implementatoin of
setlocale() doesn't call __setlocale_r(). Another
internal function was introduced to implement the common
portion that can be shared by both functions.
JAGaa32025
When memcmp is called with a negative value in the
third argument, memcmp returns an incorrect value.
The third argument is size_t which should really be
treated as a large unsigned quantity.
Resolution:
Negative values passed to memcmp() are converted to
large unsigned values and the comparison proceeds as
normal.
JAGaa24067
VxVM pathnames not recognized by blocktochar().
Resolution:
__blocktochar() and __chartoblock() routines were
rewritten to make them more general and accept any
naming convention for device files.
JAGab69351; SR 8606103064
The calling overhead for a shared library imposes
performance penalities on shared libraries. The normal
calling convention for routines that are within an
executable is a simple branch instruction. This is not
possible for shared libraries because they exist in
different spaces than the executable and they can load
to diferent addresses each time they are loaded. As a
result the calling convention requires the use of stubs
and tables to provide the mapping between the call in
the executable and the entry in the library. This will
entail a couple mispredicted branches along with the
inter-space branch.
Resolution:
The compiler has several pragmas that can be used to
cut down on the calling overhead for shared libraries.
In order to make use of these pragmas the header files
for libc needed to change to allow building the library.
JAGab15584 JAGab16669
strtod("NaN",ptr) on HPUX 11.0 incorrectly returns a ptr
past the '\0'.
Resolution:
strod(3C) code was changed to fix the incorrect behaviour.
JAGaa05185; SR 4701389726
glob(3) does not treat // consistently in a directory
path.
Resolution:
The glob(3C) was removing only the last '/' character
(if any) in a patch string. Now, glob(3C) is modified
to take care of multiple occurance of trailing '/'s in
the patch string.
JAGaa94846; SR 1653297432
The strxfrm incorrectly assumes that the variable
holding the length of the input buffer includes the
space for null character at the time of the check.
Resolution:
The algorithm for strxfrm was changed. There is a
check in this algorithm to find out if the size of
transformed string is more than the input buffer.
The condition does not take byte taken by null
character of the transformed string. This results
in null character being placed at arbitrary address.
Hence the transformed string may contain junk characters.
The condition was changed to take null character into
account.
JAGaa95471
When the getcwd() algorithm crosses a mount point on the
way to the root, it scans the entire directory containing
the mount point with stat(). When the mount point has
"sibling" directories that are also mount points, it is
very likely that the algorithm will stat() the root of
filesystems not on the current path, which is an expensive
operation both in terms of time and system resources.
Resolution:
The algorithm now remembers all mount points that it
crosses, so that it only ever needs to fully scan a
directory for a mount point once. Also, the new algorithm
pre-initializes the table of mount point names so that,
in most cases, it never needs to scan for a mount point
at all. Instead, it guesses the correct name immediately,
avoiding the expensive scan of the directory and
(possible) other remote filesystems. There are several
other minor improvements to the function to help pay for
the overhead of keeping track of mount points.
JAGaa01123, JAGaa40237
The contents of the struct utmp is cleared when end of
file is reached. But the struct utmp should be cleared
only for partial reads.
Resolution:
Code changes are done in the getut.c file to retain
the struct utmp contents when end of file is reached,
it is cleared only during partial reads.
JAGaa05209
Running the following program:
main()
{
union {
unsigned long long dbl[2];
long double ldbl;
} u;
u.dbl[0] = 0x7FFFF80000000000ULL;
u.dbl[1] = 0;
printf("%10.4Le\n", u.ldbl);
}
produces the output:
N.aN00e-01
which is incorrect.
Resolution:
Code is added to handle NAN and Infinity in case
of long double.
JAGaa86217
Excessive mutex contention and mutex locking overhead
in malloc. This was partially addressed by multiarena
malloc, but certain third-party malloc benchmarks
indicated that HP's malloc performance was still
uncompetitive.
Malloc heapsize statistics were incorrect due to
multiarena algorithm changes, which caused each arena
to contain holes belonging to other arenas. When total
heapsize was computed, these holes were overcounted
resulting in large overestimates of total heapsize.
In addition, the calculation was done under mutex lock,
which gave unacceptable performance for some third party
applications.
Multiarena malloc had assertions turned on around mutex
locks and unlocks.
Multiarena malloc aborts in 64-bits when _M_ARENA_OPTS
is set, due to a missing function prototype for getenv()
in libc_init.c.
Multiarena malloc does not allow fewer than 4 arenas
to be configured, resulting in at least 4X the
pre-multiarena memory consumption for a program which
runs threads sequentially.
Resolution:
Overview
A thread local cache is provided for each thread. Freed
blocks are cached rather than coalesced, and requests are
satisfied out of cache if possible. This provided three
performance benefits: 1) cache access does not need to
be mutexed, because it is thread private. 2) coalescence
is deferred, speeding up free(). 3) Blocks of sizes that
have previously been requested are available, and do not
need to be split if these sizes are requested again,
potentially speeding up allocation (if the same sizes tend
to be requested again).
A roughly 2X speed up over multiarena malloc has been
measured for some benchmarks.
Thread local cache is turned off by default. It can only
be turned on by setting _M_CACHE_OPTS.
Note: The thread local cache depends on a change in
libpthread which is supplied in libpthread patch
PHCO_19666. If _M_CACHE_OPTS is configured to activate
cache on a system which does not have PHCO_19666
installed, the configuration is ignored and cache is not
used.
Heapsize calculation was corrected to give accurate
values with no overcounting. A nonlocking API
(__mallstat) to report heapsize has been provided.
__mallstat() is a new HP-private API. It is planned to
be expanded for other types of statistics reporting.
Assertions have been turned off around mutex operations.
stdlib.h has been included in libc_init.c. This supplies
the function prototype for getenv().
Details about the thread local cache:
For each thread, the thread local cache layer sets up a
private cache to which access is effectively nonthreaded,
so no mutex lock is required on access. Since mutex
locking is expensive, this gives a significant
performance improvement. The thread local cache saves
blocks of sizes that have previously been used, and thus
may be requested again. It also provides deferred
coalescence of freed blocks: allocations from cache are
never split, and cached blocks are not coalesced.
The size of the cache is configurable by the number of
free pointers allocated. Once all the free pointers are
in use, in the current implementation, we never remove
anything from the cache to make room for something new.
The cache is organized as powers of 2 buckets. I.e.
there will be a bucket for all blocks in the size range
64 - 127 bytes, another for 128 - 255 bytes and so on.
Blocks are linked in the bucket in order of decreasing
size. This allows a (somewhat) better than linear search
for the best fit to a request. Currently, buckets from
2^0-31 are permitted, and the maximum is configurable.
The low end buckets are unused due to alignment, header
and padding overhead, and small block grain.
The number of cache pointers, number of buckets, and
the retirement time are configured by the environment
variable _M_CACHE_OPTS. E.g.
export _M_CACHE_OPTS=1024:32:20
This means that "__bucket_size" is 1024, "__buckets"
is 32, and "__retirement_age" is 20*60 secs (20 minutes).
[Note that in the environment variable, retirement age
is expressed in minutes, while in the internal variable
__retirement_age it is stored as seconds.] The number of
cache pointers, which equals the maximum number of buffers
that will be cached for the thread as a result of calls to
free() is __bucket_size*__buckets, or, for this example,
is 1024*32 = 32K.
If _M_CACHE_OPTS is undefined, or if it is defined but
__bucket_size is 0, then cache is disabled. If
__retirement_age is 0, retirement is disabled. The maximum
value for __bucket_size is 8*4096. The minimum is 0. The
maximum value for __buckets is 32. The minimum is 8. The
maximum value for __retirement_age is 24*60*60 seconds
(24 hours), which the user would specify in the environment
variable as 1440 minutes (24*60). The minimum value is 0.
When a thread exits, its cache is stored for reuse and it
is timestamped. As threads are created, they reuse
available caches. As threads are created or exit, if the
__retirement_age is nonzero they check whether the
difference between the timestamps of unused caches and the
current time have exceeded the __retirement_age. Those
caches that have been unused for longer than
__retirement_age are retired, i.e. all their memory is
freed with _free(). [Note that retirement is not guaranteed
to occur exactly at the time when __retirement_age is
reached, and there are possible scenarios in which unused
caches are never retired because no thread exits or starts
up.]
The mimimum number of arenas that may be configured
via _M_ARENA_OPTS has been reduced from 4 to 1. Configuring
1 arena approximates pre-multiarena behavior; with this
configuration, a program that launches threads sequentially
will not experience large increases in memory consumption
due to round-robin thread allocation to arenas.
Alternatively, activating cache allows blocks allocated by
the first thread to be reused in subsequent threads.
JAGaa40240, JAGaa01969, JAGab19981, JAGab16523, JAGab43915
JAGaa26400, JAGab43837, JAGab53676, JAGab19980;SR 8606101146
regexec() matches "." in empty string "" with locales
other than C.
Resolution:
regexec(3C) was matching a "." in an empty string "".
The problem was due to an out-of-bound array access
without checking the end-of-string. The changes made
are only to make sure that the accesses are valid.
JAGaa53114; SR 4701413906
PHCO_19491:
Libc does not know about the Magic Cookie that identifies
the these new filesystem types that will be enabled in the
future.
Resolution:
Add to the statfsdev module the identifiers for the
new filesystem types.
JAGab68821; SR 8606102818
PHCO_19391:
In a multithreaded application, if one of the threads
vforks() and does an exec(2) call(except the execve(2)
call) there is a possibility of a deadlock in the other
threads.
Memory leak in applications using vfork and exec(2)
calls except execve(2) call.
Resolution:
Fixed the deadlock in a multithreaded application,
if one of the threads vforks() and does an exec(2)
call(except the execve(2) call).
Fixed the memory leak in applications using vfork and
exec(2) calls (except execve(2) call).
JAGaa55615; SR 8606102680
Libc provides JFS ACL support through two new acl(2)
syscall:
acl()
aclsort()
JAGaa95281;SR 4701420935
Libc provides JFS support through a routine called
__fstatvxfs(). Currently, __fstatvxfs() implementation
supports only VxFS disk layout version 2 and version 3.
__fstatvxfs() needs to be updated to support the new
VxFS disk layout, version 4.
Resolution:
The following set of APIs in libc has been enhanced to
understand a VxFS filesystem with the new version 4 disk
layout:
fstatvfsdev
fstatvfsdev64
statvfsdev
This is accomplished via updating __fstatvxfs() to
understand VxFS disk layout version 4.
JAGaa95281;SR 4701420935
PHCO_19090:
atoi() calls the ctype routines isdigit() and isspace()
(although the call to isdigit() has been replaced by a
local macro in a later version). The ctype APIs are defined
only for ints -1 through 255. Any other argument causes
undefined behavior.
In our implementation, an invalid code passed to a ctype
API translates into an invalid array index which can lead
to the retrieval of an invalid value or to a segmentation
fault.
So when atoi passes a char of value greater than 127,
the char (signed) is implicitly converted to an int and
sign extension takes place since the high bit is 1. The
resulting corrupted value is then received by the ctype
API and causes undefined behavior.
Resolution:
All ctype APIs called in atoi() are passed an unsigned
char to avoid sign extension corrupting the value.
JAGab25446, JAGaa05164; SR 8606100279; SR 5003416776
PHCO_18227:
When the corefile generated by abort(3C) is read by DDE,
one of the things it checks in the stackUnwindDescriptor
is if the frame where the PC is is an alloca frame. If it
is an alloca frame, it needs to find the StackPointer in
gr3. It will then check all the frames more recent than
the one where it found the alloca frame to see if any
procedure saved off the callee save registers. If no frame
saved them, it will use the gr3 found in the save_state.
Note that the callee saved register are not saved into the
save_state in syscallinit unless the process is being
traced. The calling convention only requires a callee
saved register to be written to the stack if a function
would modify it. Hence, in the normal path of a system
call, the user register content may not be written out
to the stack at all; it could only be saved at context
switch, or it might be saved/restored on a kernel stack
at the entry/exit of a function that modifies the
register. What appears to be happening is the callee
saves are not preserved when we enter the syscall _kill().
Resolution:
Libc API abort(3C) can save the callee save registers
when entering this procedure.
JAGaa43927; SR 5003443143
If the last week of the previous year is 52 and a week
contains days in the previous years and less than 4 days
in the new year, strftime() returns week number 52 for
those days in the previous year and 53 for those in the
new year.
Resolution:
Changed strftime() to return the week number of the last
week of the previous year for weeks containing days in
the previous year and less than 4 days in the new year.
JAGaa46298
Enhance current implementation to provide multiple arenas,
each with it's own lock, from where malloc can allocate.
Threads are distributed amongst these arenas, and thus
increasing performance due to reduced lock contention.
Resolution:
This patch provides multiple arenas, where malloc can
allocate space from, and a lock for each arena. Threads
are distributed among the arenas. Two HP-UX environment
variables have been introduced, _M_ARENA_OPTS, and
_M_SBA_OPTS.
(1) _M_ARENA_OPTS can be used to tune the number of
arenas and the arena expansion factor. In general, the
more threads in an application, the more arenas should
be used for better performance. Expansion factor
controls how many pages to expand each time, assuming
the page size is 4096 bytes. The number of arenas can be
from 4 to 64 for threaded applications. For non-threaded
applications, only one arena is used. If the environment
variable is not set, or the number of arenas is set to
be out of the range, the default number of 8 will be
used. The expansion factor is from 1 to 4096, default
value is 32. Again, if the factor is out of the range,
the default value will be used. To use _M_ARENA_OPTS,
$ export _M_ARENA_OPTS=8:32
This means the number of arenas is 8, and the expansion
size is 32*4096 bytes.
In general, the more arenas you use, the smaller the
expansion factor should be, and vice versa.
(2) _M_SBA_OPTS is to turn on the small block allocator,
and set up parameters for the small block allocator,
namely, "maxfast", "grain", "num_smallblocks". (see
man page of mallopt() for details about small block
allocator, and its parameters.) Applications with
small block allocator turned on usually run faster
than with it turned off. Small block allocator can be
turned on through mallopt(); however, it is not early
enough for C++/Java applications. The environment
variable turns it on before the application starts.
Mallopt() call can still be used the same way. If the
environment variable is set, and no small block
allocator has been used, the subsequent mallopt()
calls can still overwrite whatever is set through
_M_SBA_OPTS. If the environment variable is set, and
small block allocator has been used, then mallopt()
will have no effect. To use this environment variable,
$ export _M_SBA_OPTS=512:100:16
This means the maxfast size is 512, the number of small
blocks is 100, and the grain size is 16.
You have to supply all 3 values, and in that order. If
not, the default ones will be used instead.
(3) _M_ARENA_OPTS has no effects on non-threaded cases,
while _M_SBA_OPTS has.
(4) For even better performance gains, the following
2 patches (or later ones) are recommended, PHKL_16368
(libpthread) and PHKL_16236 (kernel).
JAGaa32680
With the porting of OSF code for locales, the performance
of strcoll degraded up to 20 times. This happens because
of the generic architecture of locale engine, slow shared
library access and use of inefficient algorithms. The
performance has been enhanced a lot for single byte
locales with this fix by using better algorithms.
JAGaa00524; SR 1653214346
Single byte locales did not collate properly when an old
version of single byte locale (using multi-byte routines
for single byte locales) is used with new version of libc
(where single byte routines are used for single byte
locales). The original change was made in 10.10.
JAGaa18768, JAGaa18769
Some applications attempt to statically link with libc
to improve performance. This can lead to call graph
failures because a archive bound application is depending
on a shared library. Use of libcres.a will eliminate this
problem because there are no external dependencies in this
library.
Resolution:
Prior to this patch the only way to link various string
and memory functions archived was to link libc archived.
This leads to problems with runtime failures when the
dependent libc.sl changes and the the archive linked code
can no longer resovle the required symbols. libcres.a
contains most of the string and memory functions and a few
other functions that make no calls to other routines. Some
applications may see a performance improvement linking this
library archive while linking the rest of the application
shared.
JAGaa43395
Internal libc routines need to support VxVM volume pathname
conventions.
JAGaa42843
The libc routine memchr( ) does not perform well when static
branch prediction is enabled on executables due to a lot
branches being misprediced . This is a performance hit
when memchr is called a lot of times in executables.
JAGaa13890, JAGaa41248 ; SR 5003428409
mktime() always returns 0 for tm_isdst, regardless
of whether daylight savings is in effect for dates beyond
Tuesday January 19 03:14:07 UTC 2038. Since strptime()
obtains this value from mktime(), it also returns the
incorrect value for tm_isdst for those dates.
Resolution:
There is no timezone adjustment rule for years past 2038
that can be used to correctly determine the value of
tm_isdst. To work around this for now, the rule for the
year 2038 is used for those years.
JAGaa16206, SR 4701405688, JAGaa23230 SR 4701405696,
JAGaa23233 SR 4701405720
strptime() needs to check if the return value of
mktime() is within the range of seconds that it supports
because mktime() supports a much wider range of dates
than strptime() in 64-bit mode.
Resolution:
strptime() was modified to check the return value of
mktime() to determine if the input date is within the
supported range, which is Friday December 13 20:45:52
UTC 1901 and Friday December 31 23:59:59 UTC 9999.
JAGaa23231 SR 4701405704, JAGaa23232 SR 4701405712
In 64-bit HP-UX, getdate() needs to check if the return
value of mktime() is within the range of seconds that it
supports because mktime() supports a much wider range of
dates than getdate().
Resolution:
getdate() was modified to check the return value of
mktime() to determine if the input date is within the
supported range, which is Friday December 13 20:45:52
UTC 1901 and Tuesday January 19 03:14:07 UTC 2038 (in
32-bit HP-UX) or Friday December 31 23:59:59 UTC 9999
(for 64-bit HP-UX).
JAGaa26931 SR 4701409581
PHCO_18103:
getcwd() was using memcmp() with two structures which
were not properly initialized.
Resolution:
Replaced memcmp() call in getcwd() with comparison of
individual fields in the two structures.
JAGaa95447
PHCO_17601:
The problem was caused by excessive locking of /etc/mnttab
in the getmntent(3X) family of APIs, and by incorrect use
of the getmntent(3X) APIs by commands such as mount(1M)
and umount(1M).
Resolution:
In the patch, setmntent(3X) no longer uses a read lock
when opening the mnttab file, and a new API, delmntent(3X),
has been developed for use by commands that delete entries
from the mnttab file. Use of this patch will avoid a
possible deadlock situation during concurrent invocations
of mount(1M) or other commands that write to or read from
/etc/mnttab.
Excerpts From the Changed getmntent(3X) Man Page:
int delmntent(FILE *stream, struct mntent *mnt);
DESCRIPTION
delmntent()
Deletes all entries from the file stream opened
with setmntent that match both mnt_fsname and
mnt_dir in mntent structure mnt. If mnt_fsname is
a null pointer, all entries that match mnt_dir
will be deleted. If mnt_dir is a null pointer, all
entries that match mnt_fsname will be deleted. It
is an error if both mnt_fsname and mnt_dir are
null pointers. Note that stream must be opened
via setmntent for reading and writing (r+ or a+).
Upon return from the call to delmntent, the file
position indicator for the stream will point to
EOF.
RETURN VALUE
setmntent()
Returns a null pointer on error. setmntent()
attempts to establish an exclusive write lock on
the file it is opening, ie: when one of the
following types is passed to setmntent() to open
the file for write/update: "w", "a", "r+", "w+",
or "a+". If setmntent() cannot get the lock, it
returns a null pointer and sets errno to either
EACESS or EAGAIN.
delmntent()
Returns -1 on error. Sets errno to EINVAL if
stream or mnt are null pointers, or if both
mnt_fsname and mnt_dir in mntent structure mnt
are null pointers. Sets errno to EBADF if stream
has been opened for read (r), append (a), or
write (w). If the operation is successful,
returns the number of entries deleted from the file.
When no entries are matched, delmntent returns 0
and does not set errno.
endmntent()
Returns 1, and unlocks the file if it was locked
by setmntent().
EXAMPLES
The following code deletes an entry:
struct mntent mnt_entry;
FILE *fp;
int retval = NOT_DELETED;
mnt_entry.mnt_fsname = "/dev/vg03/lvol7";
mnt_entry.mnt_dir = "/disk7";
if ((fp = setmntent(MNT_MNTTAB, "r+")) != NULL) {
if (delmntent(fp, &mnt_entry) > 0)
retval = DELETED;
(void)endmntent(fp);
}
return(retval);
JAGaa01122, JAGaa01628
The first instruction of strlen() was a movb,=,n. The
condition code used is a 32 bit extract/deposit condition
code. Hence, if the lower 32 bits of address happen to be
zero the condition is satisfied and the branch is taken.
The same problem existed in the other three interfaces.
Resolution:
Changed the movb,=,n instruction to a cmpb,*=/copy
sequence. This instruction is functionally the same as
the movb,= but will work correctly for 64 bit addresses.
JAGaa93445; SR 4701418293
For certain years, strftime() with %V returns two
different week numbers for days in a week which
contains days in the previous year and less than 4
days in the new year. If there are less than 4 days
in the new year, it returns week number 53 for those
days, regardless of whether there is a week 53 in the
previous year; otherwise, it returns 1. It returns 52
or 53 for the days in the previous year. The week
number for the days in the new year should be the last
week of the previous year, if there are less than 4 days
in the new year in that week. In addition, the week
number for the days in the previous year should be the
same as that for the days in the new year.
---
Resolution:
Changed strftime() to return the week number of the
last week of the previous year for all days in a week
containing days in the previous year and less than 4
days in the new year. Return 1 for all days in the
week if there are 4 or more days in the new year.
JAGaa62691
An internationalized application encounters the memory
leak at every
setlocale(category, locale);
call to change the locale environment under any
condition except:
o LC_ALL environment variable is not set;
o Category parameter is LC_ALL; and
o Locale parameter is (explicitly specified) "C" or
"POSIX".
Most internationalized applications call the setlocale()
function in the form of:
setlocale(LC_ALL, "");
and encounter the memory leak if the call is made more
than once. Therefore, this patch should be installed
if an application needs to call the setlocale() function
more than once.
Resolution:
Necessary memory to save the locale specific information
used to be dynamically allocated at every setlocale()
call without freeing the memory allocated by the previous
call. The implementation has been changed to free the
previously allocated memory at every call before
allocating the new memory.
JAGaa92941; SR 1653294694
A socket used in libc times out, causing synchronization
loss and connection reliability problems.
Resolution:
The problem was solved by comparing the returned values
to that in the request.
JAGaa46458, JAGaa72866; SR 1653284414; SR 1653287904
The check for whether the root directory has been
reached in the case of a Loop Back File System (LOFS)
was not done correctly in getcwd().
Resolution:
Changed getcwd() to fill in the entire mystat structure
for the current directory and its parent directory and
then compare the entire two structures. The previous
code only compares the inode and device numbers. This
change ensures that cases where the inode and device
numbers are the same for both the current and parent
directory will be handled correctly.
An example of this, prior to apply the fix to getcwd(),
follows:
# mount /stand /stand/lofs
# cd /stand/lofs/build
# pwd
/build /* path obtained from getcwd() */
This is because the inode and device numbers for lofs
and stand are the same:
build: {ino = 4226; dev = 0x40000001; fstype = lofs;
fsid = 0xff000004}
lofs: {ino = 5376; dev = 0x40000001; fstype = lofs;
fsid = 0xff000004}
stand: {ino = 5376; dev = 0x40000001; fstype = ufs;
fsid = 0 }
/: {ino = 2; dev = 0x40000001; fstype = ufs;
fsid = 0 }
JAGaa86037; SR 4701416800
PHCO_16629:
memcmp(3C) returns incorrect values when compiled with
+DA2.0N. This is due to some recent performance
optimizations that were done on memcmp, which introduced
a problem where 64 bit registers are compared with 32 bit
compare instructions. This causes the upper 32 bits to be
ignored, which causes memcmp to return incorrect values.
memcmp also performs 64 bit compare operations on 32 bit
operands passed as parameters to these routines. This could
cause problems with high optimization which could leave the
upper 32 bits dirty and hence make memcmp return unexpected
results.
JAGaa41144, JAGaa41248; SR 5003438507
The performance of malloc has been improved by changing
the way the free memory blocks are maintained.
JAGaa17260
Parameters between 64-bit C code and 64-bit assembly
code were being passed incorrectly.
JAGaa35268, JAGaa32697, JAGaa40380
There was a performance degrade in some cases.
JAGaa40211
The ELF version of the linker enables SHLIB_PATH by
default.
JAGaa22065
setjmp/longjmp did not call the CXperf tool function
with the correct first parameter.
JAGaa32076
A performance enhancement for threaded applications
changed the grain size causing threaded applications
to use more memory.
JAGaa32072
PHCO_16130:
If old 10.20 locale which uses multi-byte routines
is used and it has collating element e.g. spanish,
strcoll and wcscoll will not perform correctly.
JAGaa18768, JAGaa18769
strptime(3C) returns an error when the %E conversion
specification is used in the C locale. It does not
fill in the tm_wday, tm_mon and tm_mday fields in the
tm structure when both the year and day of year are
supplied. It does not support dates beyond January
19 UTC 2038 in 32-bit HP-UX. It does not indicate
an error when a date that is out-of-range or
inconsistent input is provided. The resulting values
of tm_wday and tm_yday are off by 1 when tm_sec and/or
tm_min are initialized to -1 when the %j conversion
specification is used.
JAGaa06544; SR 5003416719
strptime() returns the same values for the tm_mday, tm_mon,
tm_yday and tm_wday fields in the tm structure for Feb 29
2000 and March 1 2000 if %A (or %a) and %U conversion
specifications are used. The output for March 1 2000 is
incorrect.
JAGaa13581; SR 1653269738
A call to getcwd() will fail if the root file system
is a loopback file system. This will not normally be
the case, but if chroot() has been called to set the
root directory, then this could be a loopback file
system (LOFS). A specific example of this is when
the anonymous ftp home directory is a LOFS as ftpd
will then use chroot() and can report:
550 getcwd: No such file or directory
JAGaa11165, JAGaa01441, JAGaa05219, JAGaa06021
SR#4701382374
getenv runs very slow for multi-byte languages like
ja_JP.SJIS. The performance for single-byte
languages is as good as C locale. JAGaa05075
SR#1653259333; JAGaa50639
getdate() fails to find a matching template when %r is used
in a template and there is at least one other template that
contains %H or %R, even though a matching template exist.
It also returns an error if a template contains %I but not
%p and a matching template exists.JAGaa00429, JAGaa10165,
JAGaa10166, JAGaa10167, JAGaa10168,JAGaa05222, JAGaa10164,
JAGaa10163, JAGaa08067, JAGaa10158,JAGaa12392;
SR 4701392977; SR 4701392969 ;SR 1653261081; SR 4701392928
SR 4701394650
The libc routine memcmp( ) does not perform well when static
branch prediction is enabled on executables due to the
high branch misprediction. This is a performance hit when
memcmp is called a lot of times in executables. JAGaa06535
PHCO_15768:
A flag in __regcomp_std() was set incorrectly which
caused the "match end of line" not being recognized.
Setting of the flag is corrected. JAGaa01206
Commands dump core if LC_COLLATE is set to non C
locale but LC_CTYPE is set to C locale. If there
is no difference between LC_COLLATE and LC_CTYPE,
there is no problem. JAGaa01206
The calculation for length of string in __strnlen() API
for 64-bit mode was incorrect. JAGaa01674
The previous syslog code, in some places, kept filling
the buffers without checking for the buffer limits.
Once the size of buffers were exceeded a core dump
would occur. JAGaa01271
Original usleep(3C) code didn't have the functionality to
handle multi-threaded applications. Now it uses
sigtimedwait(2) for handling threaded applications.
JAGaa01457
When Null pointer was being passed as argument for fputs
and puts, fputs should return 0 and write nothing to the
file, puts should return 1 and write '\n' to stdout.
JAGaa01279 JAGaa01511 JAGaa01513 JAGaa01515
The 5th and 8th arguments are corrupted during the course
of execution of syscall() API. JAGaa04782
The fix to setjmp() function in patch PHCO_14102 didn't
take care of case where the program is compiled with
64-bit mode (+DA2.0W) and -z compiler option.
JAGaa01982
PHCO_14704:
"struct stat64" in the internal 64-bit interfaces
(i.e. __ftw64(), __nftw64() and __nftw2_64()) needs to
be changed to "struct stat" to be consistent with the
changes made to ftw.h to provide Large Files support
for C++ applications. This change is needed in order
for libc to compile with the changes in ftw.h and has
no effect on functionality. JAGaa01664.
Mutex was not released before returning to the
caller when sigspace() is called by the process
running on the alternate signal stack; a single
memory space was shared among all threads within
a process. JAGaa01033 JAGaa01062
There was an assumption that more than 254 arguments
wouldn't be passed to execvp(). This number was
hard-coded in the implementation. JAGaa00583
Enhancement request for providing a new threads API
__thread_detach(). JAGaa01380
An internal function called by glob() attempts to free()
the same block twice. JAGaa01494
This is an enhancement request to provide jmp_buf pointer
in the hook functions of HP CXDL Development Tool. These
hooks are called from setjmp() and longjmp() APIs while
applications are linked with HP CXDL Development Tool.
JAGaa01603
Memccpy() doesn't detect the value of 0 at address 0.
JAGaa01280
This regcomp() defect was caused by copying one NULL
string pointer to another without any checking.
JAGaa01396, JAGaa01496, JAGaa01497
strptime(3C) does not produce the correct week number for
dates in a year that begins on a Sunday or a Monday.
JAGaa00976 1653231456
getlogin(3) API in libc returns NULL when the tty is
console. Hence the utilities like passwd print error
messages when they use getlogin() API to access the
login name of the user. JAGaa00533 5003380394
The gets(3S) API can fail to release a lock after
encountering an EOF condition. This will cause another
thread in the application doing an i/o operation on stdin
to hang, leading potentially to an application deadlock.
JAGaa01583 ;SR 4701384214
Code cleanup done in getcwd.c. User behavior unchanged.
JAGaa01101
PHCO_14102:
The problem was introduced with the addition of a new
symbol in API malloc().
Support for CXperf performance tool was added in
setjmp/longjmp() family of calls. If application is run
with CXperf tool, then setjmp/longjmp() APIs have mechanism
coded in order to gather correct performance statistics.
HP-UX enforces that variable lengthes should not exceed
1024. In catopen(3C), the string that represents the
variable LANG was strcpy'ed into a buffer with a fixed
size MAXPATHLEN (1024). This caused
coredump when strlen(LANG) is longer than 1024.
The size of the string, passed to perror, plus message was
not checked and could have become larger than the size of
the allocated output buffer. In such situations perror
would have coredumped.
Signal mask was not restored for this corner case.
This problem only occurs when 1) large malloc has been
enabled, ie: the M_ENABLE_MMAP command has been passed to
mallopt(), and 2) the initial size request to malloc() is
so large that malloc() searches all 4 memory quadrants and
it is unable to find a large enough block.
In the event that times(2) fails in a multi-threaded
application, clock(3C) does not release the mutex. This
will cause the next thread that invokes clock() to wait
forever for the mutex, in effect, causing the application
to loop forever.
NIS uses dbm to to manage its data. Because of unlucky
splitting, the '.pag' file has a large empty area which
causes the NIS file transfer to fail because it takes
longer than 25 seconds for dbm to get between keys.
PHCO_13412:
The assembly code expects the quad floating point
information to be passed by address. The C code that calls
it is passing it by value. In 32-bit this pass by value
would be converted to an address. In 64-bit it is passed by
value.
PHCO_13283:
The setjmp(3c)/longjmp(3c) APIs did not have a mechanism
which enabled correct performance statistics to be gathered
with the HP CXDL Development Tools.
The implementation of the wcswidth(3c) API fails to
comply with specification if the locale dependent
version of wcswidth does not comply.
When calling sigsetjmp() and then siglongjmp() from
non-position independent code. GR is not saved.
Enhancement:
No (superseded patches contained enhancements)
PHCO_25976:
Enhancements were delivered in this patch or one it has
replaced.Please review the Defect Description text for
more information.
SR:
8606261730 8606231691 8606254777 8606238389 8606262356
8606256907 8606125689 8606243323 8606225355 8606199060
8606206070 8606211883 8606205180 8606213123 8606204965
8606215364 8606194394 8606217381 8606202970 8606203226
8606158464 8606212783 8606196622 8606186527 8606165366
8606177629 8606178299 8606179946 8606172344 8606188513
8606196866 8606185984 8606133330 8606164457 8606170481
8606172179 8606162140 8606128089 8606130241 8606152550
8606129543 8606175166 8606143128 8606102984 8606147002
8606134279 8606141866 8606156311 8606129009 8606140246
8606136018 8606126100 5003424531 8606125006 8606125009
8606125010 8606125320 8606125513 8606107568 8606104124
8606106738 8606106516 8606104837 5003444117 5003463463
8606103064 4701389726 1653297432 4701413906 8606102818
4701420935 8606100279 5003443143 1653214346 4701405688
4701405696 4701405720 4701405704 4701405712 4701409581
4701414862 1653294694 1653284414 4701418293 5003438507
5003416719 1653269738 4701374496 4701374470 4701374504
4701376756 5003392126 1653228304 1653119560 5003156760
5003380394 1653231456 1653259333 4701382374 1653255513
1653257121 1653261081 1653287904 1653294272 4701382259
4701384214 4701385336 4701389916 4701390120 4701391243
4701392928 4701392969 4701392977 4701394395 4701394650
4701416800 5003396234 5003416776 5003428409 5003436451
5003436923 8606101146 8606102680 8606104633 8606106818
8606106824 8606106825 8606106827 8606108045 8606109096
8606109646 8606112024 8606114983 8606114986 8606114988
8606114994 8606115002 8606115130 8606239637
Patch Files:
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libc.a
/usr/lib/libcres.a
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libc.a
/usr/lib/pa20_64/libcres.a
OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libc.2
OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libc.2
ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libp/libc.a
ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libp/libc.a
ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libpicc.a
what(1) Output:
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libc.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 11:02:20 $
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libcres.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 11:22:05 $
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libc.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 18:54:36 $
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libcres.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 18:58:45 $
OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libc.2:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 18:52:28 $
OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libc.2:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 10:59:33 $
ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libp/libc.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 11:08:51 $
ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/pa20_64/libp/libc.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 18:57:34 $
ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/lib/libpicc.a:
$ PATCH/11.00:PHCO_27608 Aug 12 2002 11:00:04 $
cksum(1) Output:
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
1181039264 2187296 /usr/lib/libc.a
OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
179826478 68056 /usr/lib/libcres.a
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
3668296051 3676258 /usr/lib/pa20_64/libc.a
OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
3693152237 67350 /usr/lib/pa20_64/libcres.a
OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
4264719584 1572640 /usr/lib/pa20_64/libc.2
OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
3074616320 1560576 /usr/lib/libc.2
ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
4277032079 2559616 /usr/lib/libp/libc.a
ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
fa=HP-UX_B.11.00_32/64,v=HP:
1151811204 4064416 /usr/lib/pa20_64/libp/libc.a
ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
1166767612 2328656 /usr/lib/libpicc.a
Patch Conflicts: None
Patch Dependencies:
s700: 11.00: PHCO_23092 PHKL_18543 PHKL_20236 PHKL_22677
s800: 11.00: PHCO_23092 PHKL_18543 PHKL_20236 PHKL_22677
Hardware Dependencies: None
Other Dependencies:
PHCO_24148: JAGab20870
The tzset() behaviour have been changed to take default TZ
values from the file /etc/default/tz. A sample file is
released as patch PHCO_23652. The /etc/default/tz included
in the patch contains the earlier default value ie.,
EST5EDT. So unless the user explicitly changes the value
contained in the file the tzset changes are transparent to
the user. The file /etc/default/tz contains the timezone
value set by tzset() when the environment variable TZ is not
set. The format for the file is same as TZ format without
the prefix "TZ=". Please check environ(5) for TZ format.
The order of TZ setting is as follows.
1) if the environment variable TZ is present, it takes the
precedence.
2) if TZ is not present, then the value contained in
/etc/default/tz is used for default.
3) if /etc/default/tz is not set, then the default value is
equivalent to EST5EDT (Eastern Standard Time) of US.
Supersedes:
PHCO_13283 PHCO_13412 PHCO_14102 PHCO_14704 PHCO_15768 PHCO_16130
PHCO_16629 PHCO_17601 PHCO_18103 PHCO_18227 PHCO_19090 PHCO_19391
PHCO_19491 PHCO_19691 PHCO_20369 PHCO_20555 PHCO_20763 PHCO_20765
PHCO_22076 PHCO_22314 PHCO_22923 PHCO_23770 PHCO_24148 PHCO_24723
PHCO_25707 PHCO_25976
Equivalent Patches: None
Patch Package Size: 17840 KBytes
Installation Instructions:
Please review all instructions and the Hewlett-Packard
SupportLine User Guide or your Hewlett-Packard support terms
and conditions for precautions, scope of license,
restrictions, and, limitation of liability and warranties,
before installing this patch.
------------------------------------------------------------
1. Back up your system before installing a patch.
2. Login as root.
3. Copy the patch to the /tmp directory.
4. Move to the /tmp directory and unshar the patch:
cd /tmp
sh PHCO_27608
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHCO_27608.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHCO_27608. If you do not wish to retain a
copy of the original software, include the patch_save_files
option in the swinstall command above:
-x patch_save_files=false
WARNING: If patch_save_files is false when a patch is installed,
the patch cannot be deinstalled. Please be careful
when using this feature.
For future reference, the contents of the PHCO_27608.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHCO_27608.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHCO_27608.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
PHCO_25976: JAGac42568
If the file /etc/utmpx(4) is corrupted, it may cause a
lockout and users (including root) may not be able to login
to the system. This is due to a defect fix SR: 8606125689
(JAGac42568) introduced to verify the file /etc/utmpx and
which is in accordance with the getutx(3C) man page.
The file /etc/utmpx is considered to be corrupted if the
following command reports a number other than zero (i.e.
its size is not evenly divisible by the record size 140):
(ll /etc/utmpx | awk '{print $5}'; echo "140 %p") | dc
To resolve this problem it is advisable to clear the file
/etc/utmpx by following this procedure:
Before installing this libc GR patch insert the following
line into the /etc/inittab(4) file
utm1::sysinit:> /etc/utmpx # clear the file /etc/utmpx
just after the line
init:3:initdefault:
Here is an example:
init:3:initdefault:
utm1::sysinit:> /etc/utmpx # clear the file /etc/utmpx
After adding this line to /etc/inittab and installing this
libc patch, reboot the system to clear /etc/utmpx if it is
corrupted. If the system cannot be rebooted now, delay
installing the libc patch.
The file /etc/utmpx will be cleared every time the system
is rebooted.
If libc patches are installed without rebooting,
applications currently running which are linked shared
against libc will still continue using the former version of
libc. If this presents a problem to any applications, you
should reboot.
|
Printable version
