Patch Name: PHCO_24958 Patch Description: s700_800 11.20 libc PA compatibility patch Creation Date: 01/08/23 Post Date: 01/09/14 Hardware Platforms - OS Releases: s700: 11.20 s800: 11.20 Products: N/A Filesets: OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP Automatic Reboot?: No Status: General Release Critical: Yes PHCO_24958: CORRUPTION HANG Category Tags: defect_repair general_release critical halts_system corruption Path Name: /hp-ux_patches/s700_800/11.X/PHCO_24958 Symptoms: PHCO_24958: ( SR:8606165164 CR:JAGad34460 ) mallinfo() returns incorrect arena/uordblks. ( SR:8606177629 CR:JAGad46861 ) ptsname corrupts heap SIGBUS may result. ( SR:8606196622 CR:JAGad65825 ) Multithreaded application core dumps sometimes when it uses the Name Service Switch calls like getXXent and endXXent. ( SR:8606186527 CR:JAGad55731 ) M_BLOCK behavior for malloc not working correctly. ( SR:8606185046 CR:JAGad54248 ) malloc(3C) has a silent data corruption in fourth quadrant. ( SR:0000000000 CR:JAGab20870 ) When environment variable TZ is not set, the variables tzname[2] and timezone is set to hard coded values corresponding to Eastern Standard Time. ( SR:8606172344 CR:JAGad41604 ) (1) Trusted system calls made on an 11.0 NIS system causes a SIGSEGV core dump. (2) Using "dns" as a source for databases other than "hosts" causes a SIGSEGV core dump. ( SR:8606194571 CR:JAGad63779 ) getdate 26 via VSU test case unresolved Defect Description: PHCO_24958: ( SR:8606165164 CR:JAGad34460 ) mallinfo() 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 lastbrk != curbrk. The dummy header which had SIZE=0 and USED set, will be set with the difference of curbrk and lastbrk. If the lastbrk of one thread is not equal to the curbrk, the possibility is that either user application called brk/sbrk or some other thread expanded the brk value. If the curbrk value is changed from some other thread 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 The problem is because of setting USER_ID when the other arena calls brk/sbrk. Resolution: The resolution is basically to avoid the use of USER_ID when the other arena calls brk/sbrk. A new memory block identifier ARENA_ID is defined in malloc.c as 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. O 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. ( SR:8606177629 CR:JAGad46861 ) 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. Resolution: In ptsname funciton after allocating the memory, the number of bytes allocated is passed to GET_TSS() function instead of passing the character pointer returned by malloc(). ( SR:8606196622 CR:JAGad65825 ) 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. ( SR:8606186527 CR:JAGad55731 ) 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. ( SR:8606185046 CR:JAGad54248 ) The defect was due to coalescing when the allocation is switched from sbrk to mmap at 4th quadrant. The coalescing was resulting to allocating the blocks of memory near the stack, which leads to data corruption. Resolution: Resolution is to avaiod coalescing near the quadrant 4 boundry. ( SR:0000000000 CR:JAGab20870 ) 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. ( SR:8606172344 CR:JAGad41604 ) 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. ( SR:8606194571 CR:JAGad63779 ) vs5.03 fixed test case for unix98 but the fix is incomplete with unix95 testing. the input string for getdate(this case 11:12) do not match the format in ApTest locale(t_fmt %I@%M@S %p) the test case is using. In UNIX98, the t_fmt in locale is not referenced but it is in UNIX95. So the test case don't work for unix95 testing. Resolution: The test case is in line with UNIX 98. Changed the getdate behaviour to be in line with UNIX98. SR: 0000000000 8606165164 8606172344 8606177629 8606185046 8606186527 8606194571 8606196622 Patch Files: OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: /usr/lib/pa20_64/libc.2 OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: /usr/lib/libc.2 /usr/lib/pa20_32/libc.2 what(1) Output: OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: /usr/lib/pa20_64/libc.2: None OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: /usr/lib/libc.2: None /usr/lib/pa20_32/libc.2: None cksum(1) Output: OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: 3762991304 1801880 /usr/lib/pa20_64/libc.2 OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP: 2808962405 1810432 /usr/lib/libc.2 350239637 1761280 /usr/lib/pa20_32/libc.2 Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: None Equivalent Patches: None Patch Package Size: 5280 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_24958 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHCO_24958.depot By default swinstall will archive the original software in /var/adm/sw/save/PHCO_24958. 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_24958.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHCO_24958.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHCO_24958.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None