
PROBLEM: (91106) (PATCH ID: OSF520-332)
********
libaio dumps core because of a ./usr/ccs/lib/libaio.a memory fault during 
aio_cancel with the following stack trace (output trimmed for readability:
thread 0x14 signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff8057d6d8]
(dbx) t
>  0 __nxm_thread_kill() [0x3ff8057d6d8]
   1 pthread_kill() [0x3ff80576510]
   2 (unknown)() [0x3ff80581a98]
   3 (unknown)() [0x3ff807e3aa0]
   4 exc_raise_signal_exception() [0x3ff807e3e90]
   5 (unknown)() [0x3ff80577ff0]
   6 (unknown)() [0x3ff81085588]
   7 aio_cancel() [0x3ff81085804]

This problem has never been seen in the field and was only uncovered by a 
test progam that severly exercises and stresses the aio_cancel() function.


PROBLEM: (HPAQC1TZ5) (PATCH ID: OSF520-392)
********
Support for up to NEW_OPEN_MAX_SYSTEM (64K) file descriptors added to libaio.


PROBLEM: (CH_G03471, 92575, 87500) (PATCH ID: OSF520-466)
********
When both libaio and libaio_raw are linked into the same image, the run-time
environment will execute both __init_aio routines - which register prefork
handlers that take a mutex.  This causes the prefork handler to be called twice
by the same thread.  The first gets the mutex and the second blocks... forever.
Closed a race condition when an AIO request was cancelled before the 
thread created to handle the request was dispatched.  Stale global data 
generated the "inconsistency" check.  The thread now detects this condition 
and recovers gracefully.  The race condition may result in a process exit
displaying: Internal AIO consistency error: No thread pointer at
fd X. Aborting".



