A "fix" for bug no. 2 is to check if the process slot has disappeared.

Not a really good solution (as it might not catch situations in which this
is caused by another bug), but the forrest of checks necessary might be worse
than this quick fix - because when looking for the cause, I found some other
cases in which the PM would panic as well. See info in bug 2 for details.

Another fix is to delay notification of PM by SYSTASK of signals delivered
internally until after the reply (e.g. of exec()), because the reply would
be messed up otherwise (receiving the notify instead of reply). This caused
SIGTRAP not to be delivered properly with traced processes.

servers/pm/main.c

@@ -75,7 +75,13 @@ PUBLIC void main()
 	 * the call just made above.  The processes must not be swapped out.
 	 */
 	for (proc_nr=0, rmp=mproc; proc_nr < NR_PROCS; proc_nr++, rmp++) {
-		if ((rmp->mp_flags & (REPLY | ONSWAP)) == REPLY) {
+		/* In the meantime, the process may have been killed by a
+		 * signal (e.g. if a lethal pending signal was unblocked)
+		 * without the PM realizing it. If the slot is no longer in
+		 * use or just a zombie, don't try to reply.
+		 */
+		if ((rmp->mp_flags & (REPLY | ONSWAP | IN_USE | ZOMBIE)) ==
+		   (REPLY | IN_USE)) {
 			if ((s=send(proc_nr, &rmp->mp_reply)) != OK) {
 				panic(__FILE__,"PM can't reply to", proc_nr);
 			}