Patch Name: PHCO_25241

Patch Description: s700_800 11.20 libc cumulative patch

Creation Date: 01/10/03

Post Date:  01/10/09

Hardware Platforms - OS Releases:
	s700: 11.20
	s800: 11.20

Products: N/A

Filesets:
	OS-Core.C-MIN,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP
	OS-Core.C-MIN-64ALIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP
	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
	ProgSupport.PROG-AUX,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP

Automatic Reboot?: No

Status: General Release

Critical:
	No (superseded patches were critical)
	PHCO_24870: CORRUPTION HANG

Category Tags:
	defect_repair enhancement general_release critical
	halts_system corruption

Path Name: /hp-ux_patches/s700_800/11.X/PHCO_25241

Symptoms:
	PHCO_25241:
	( 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.

	PHCO_24870:
	( SR:8606197956 CR:JAGad67147 )
	strftime() fails to interpret the precision field

	( SR:8606165366 CR:JAGad34660 )
	mallinfo() returns incorrect arena/uordblocks

	( 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.

Defect Description:
	PHCO_25241:
	( 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.

	PHCO_24870:
	( SR:8606197956 CR:JAGad67147 )
	strftime() fails to interpret the precision field

	Resolution:
	Resolution is to check the precision field first before
	checking the  width of the multibyte character.

	( SR:8606165366 CR:JAGad34660 )
	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: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 8606165366 8606185046 8606186527 8606197956

Patch Files:
	
	OS-Core.C-MIN,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/unix95.o
	/usr/lib/hpux32/unix98.o

	OS-Core.C-MIN-64ALIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux64/unix95.o
	/usr/lib/hpux64/unix98.o

	OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux64/libc.so.1

	OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/libc.so.1
	/usr/lib/hpux32/libcres.a
	/usr/lib/hpux64/libcres.a

	ProgSupport.PROG-AUX,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/libp/libc.so.1
	/usr/lib/hpux32/libp/libcres.a
	/usr/lib/hpux64/libp/libc.so.1
	/usr/lib/hpux64/libp/libcres.a

what(1) Output:
	
	OS-Core.C-MIN,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/unix95.o:
		None
	/usr/lib/hpux32/unix98.o:
		None

	OS-Core.C-MIN-64ALIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux64/unix95.o:
		None
	/usr/lib/hpux64/unix98.o:
		None

	OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux64/libc.so.1:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:31:11 $
		HP-UX/General Millicode UX.12.70 (IA64.ISV3): (MILLI
			 - 02/13/01)

	OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/libc.so.1:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:17:29 $
		HP-UX/General Millicode UX.12.70 (IA64.ISV3): (MILLI
			 - 02/13/01)
	/usr/lib/hpux32/libcres.a:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:58:54 $
	/usr/lib/hpux64/libcres.a:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:59:08 $

	ProgSupport.PROG-AUX,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	/usr/lib/hpux32/libp/libc.so.1:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:50:54 $
		HP-UX/General Millicode UX.12.70 (IA64.ISV3): (MILLI
			 - 02/13/01)
	/usr/lib/hpux32/libp/libcres.a:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:59:39 $
	/usr/lib/hpux64/libp/libc.so.1:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:57:07 $
		HP-UX/General Millicode UX.12.70 (IA64.ISV3): (MILLI
			 - 02/13/01)
	/usr/lib/hpux64/libp/libcres.a:
		$ PATCH_11.20/PHCO_25241  Oct  3 2001 16:59:53 $

cksum(1) Output:
	
	OS-Core.C-MIN,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	4038405204 960 /usr/lib/hpux32/unix95.o
	2330385123 960 /usr/lib/hpux32/unix98.o

	OS-Core.C-MIN-64ALIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	3117678936 1200 /usr/lib/hpux64/unix95.o
	3980445748 1200 /usr/lib/hpux64/unix98.o

	OS-Core.CORE-64SLIB,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	2117803979 2686656 /usr/lib/hpux64/libc.so.1

	OS-Core.CORE-SHLIBS,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	831512947 2858712 /usr/lib/hpux32/libc.so.1
	798015350 57034 /usr/lib/hpux32/libcres.a
	44785974 64270 /usr/lib/hpux64/libcres.a

	ProgSupport.PROG-AUX,fr=B.11.20,fa=HP-UX_B.11.20_64,v=HP:
	236862068 3088768 /usr/lib/hpux32/libp/libc.so.1
	3161380111 62978 /usr/lib/hpux32/libp/libcres.a
	431115071 2913264 /usr/lib/hpux64/libp/libc.so.1
	1050118593 72174 /usr/lib/hpux64/libp/libcres.a

Patch Conflicts: None

Patch Dependencies: None

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHCO_24870 

Equivalent Patches: None

Patch Package Size: 11580 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_25241

	5. Run swinstall to install the patch:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -s /tmp/PHCO_25241.depot

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHCO_25241.  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_25241.text file is 
	available in the product readme:

		swlist -l product -a readme -d @ /tmp/PHCO_25241.depot

	To put this patch on a magnetic tape and install from the
	tape drive, use the command:

		dd if=/tmp/PHCO_25241.depot of=/dev/rmt/0m bs=2k

Special Installation Instructions: None