"Julian Graham" <[EMAIL PROTECTED]> writes:
> On Jan 24, 2008 8:38 PM, Julian Graham <[EMAIL PROTECTED]> wrote:
>> > - we apply the generic / bug fix patch that you already posted, except
>> > without the extra thread_admin_mutex locking (which I think we
>> > concluded we can't justify) - that will be to HEAD
>>
>> Agreed, though see below...
>
>
> Actually, in light of Neil's apt suggestion that we get this thing
> back on track, I resolve to stop fussing about deadlocks for the time
> being -- find attached the patch described above (1 deadlock -- the
> jmpbuf critical section one -- and the thread-specific mutex).
Thanks.
> Let me know if I've missed anything.
I don't think so, and I plan to apply this very soon. I've found a
reliable recipe for reproducing the critical section problem: if a
scm_i_gc call is added to make_jmpbuf (), like this:
static SCM
make_jmpbuf (void)
{
SCM answer;
SCM_CRITICAL_SECTION_START;
{
scm_i_gc ("test");
SCM_NEWSMOB2 (answer, tc16_jmpbuffer, 0, 0);
SETJBJMPBUF(answer, (jmp_buf *)0);
DEACTIVATEJB(answer);
}
SCM_CRITICAL_SECTION_END;
return answer;
}
Then "make check" hangs every time, in the way you described, when
running the system* part of test-suite/standalone/test-system-cmds.
(It happens because scm_system_star calls scm_sigaction, which calls
ensure_signal_delivery_thread, which spawns a new thread; and then
immediately after that, scm_sigaction enters a critical section.)
So now I just want to find a way of making this happen regressibly,
without actually adding the scm_i_gc call to the checked in code.
Regards,
Neil
