Re: Deadlock when receiving kill-signal from child process

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 5, 10:11pm, Mathias Fredriksson wrote:
} Subject: Re: Deadlock when receiving kill-signal from child process
}
} On Wed, Aug 5, 2015 at 9:52 PM, Bart Schaefer wrote:
} }
} } Hm.  I'm a little puzzled by the continued appearance of the "no job
} } table entry" warning but this --
} 
} Is it not explainable by disowning the child process (child &!)? At
} least when I only do "child &" the error disappears.

That explains the ./deadlock.zsh:... warnings but I didn't think it
explained the one that happened in TRAPUSR1.  Probably not significant.

} #0  0x00007fff8abfe166 in __psynch_mutexwait ()
} #1  0x00007fff8e4b578a in _pthread_mutex_lock ()
} #2  0x00007fff82ce5750 in fputc ()
} #9  <signal handler called>
} #23 0x00007fff853a9340 in OSAtomicCompareAndSwapPtrBarrier$VARIANT$mp ()
} #24 0x00007fff8e4b5714 in _pthread_mutex_lock ()
} #25 0x00007fff82ce43a3 in ferror ()

Dang.  Not sure there's much we can do about that one, that's the stdio
library deadlocking internally on a mutex because a signal arrived.
It'd be pretty ugly for us to try to wrap every stdio call with signal
blocking.


} #17 0x00007fff896d9ccf in szone_free_definite_size ()
} #18 0x00000001050ae85c in init_parse ()

Yet another one of these.  We may have to resort to treating all signals
the way we treat WINCH, that is, having them constantly queued except
for specific moments when we unqueue them.

diff --git a/Src/parse.c b/Src/parse.c
index 09567fd..84ebf85 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -456,6 +456,8 @@ init_parse_status(void)
 void
 init_parse(void)
 {
+    queue_signals();
+
     if (ecbuf) zfree(ecbuf, eclen);
 
     ecbuf = (Wordcode) zalloc((eclen = EC_INIT_SIZE) * sizeof(wordcode));
@@ -466,6 +468,8 @@ init_parse(void)
     ecnfunc = 0;
 
     init_parse_status();
+
+    unqueue_signals();
 }
 
 /* Build eprog. */

-- 
Barton E. Schaefer