PROBLEM:  (QAR 69251)    (Patch ID: OSF440-054)
********
In the latest development version (version 52), Ladebug has has begun to
employ a "user thread hold" mechanism.  The initial testing of this mechanism
has revealed bugs in DECthreads code bases which might result in missed
breakpoints and watchpoints, as well as causing application hangs.

PROBLEM:  (CLD HPAQ21HQ9)    (Patch ID: OSF440-054)
********
Customer was encountering an invalid scheduling priority bugcheck, which
appears to be caused by incorrect referencing of scheduling data structures
inside DECthreads.

PROBLEM:  (QAR 69364)    (Patch ID: OSF440-054)
********
The manager thread is being scheduled to run in response to a system event
(nxm action, timer queue expiration, etc) but is not recognizing the event
as the reason it was scheduled to run.
  
The manager thread then goes back to sleep, only to wake up again in response
to the still unserviced system event.  An infinite loop results.

PROBLEM:  (QAR 70833)    (Patch ID: OSF440-111)
********
DECthreads turns synchronous signals into exceptions for processing
by the application program with TRY...ENTRY blocks.  If no application
TRY block exists, processing defaults to the DECthreads internal routine,
excLastChance.  Prior to this patch, excLastChance would only reset the
handler for the signal if the handler was the DECthreads-installed
sigRaiseException routine. Any application-installed handlers remained.
This caused a problem for applications whose signal handlers attempt to
pass control to previously installed signal handlers, because if the
previously installed handler was sigRaiseException, an infinite loop would
result.

PROBLEM:  (QARs 71019, 71358)    (Patch ID: OSF440-111)
********
A bug in the DECthreads two-level scheduler was causing Virtual Processors
(VPs) to go idle and never be scheduled to run.  This resulted in one or more
CPUs on SMP machines going unused by threaded applications.