Although a SEMAPHORE's mutex is private to that SEMAPHORE, and the
mutex is released during the wait in WAIT-ON-SEMAPHORE, it's still
possible to starve in SIGNAL-SEMAPHORE while waiting to acquire the
mutex because a deadline handler around WAIT-ON-SEMAPHORE could be
running in the implicitly called CONDITION-WAIT which reacquires the
mutex.
Hence make sure that the call to GET-MUTEX in SIGNAL-SEMAPHORE is
interruptable.
   * bug fix: a rare case of startup-time page table corruption.
   * bug fix: a semaphore with multiple waiters and some of them unwinding due
     to timeouts could be left in an inconsistent state.
+  * bug fix: fix typo in "Reporting Bugs" section of the manual (lp#520366)
 
 changes in sbcl-1.0.37 relative to sbcl-1.0.36:
   * enhancement: Backtrace from THROW to uncaught tag on x86oids now shows
 
   (declare (type (integer 1) n))
   ;; Need to disable interrupts so that we don't lose a wakeup after
   ;; we have incremented the count.
-  (with-system-mutex ((semaphore-mutex semaphore))
+  (with-system-mutex ((semaphore-mutex semaphore) :allow-with-interrupts t)
     (let ((waitcount (semaphore-waitcount semaphore))
           (count (incf (semaphore-%count semaphore) n)))
       (when (plusp waitcount)
 
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.37.12"
+"1.0.37.13"