bug#36609: 27.0.50; Possible race-condition in threading implementation

[Pip Cet]

On Fri, Jul 12, 2019 at 1:31 PM Eli Zaretskii <eliz@gnu.org> wrote:>
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Fri, 12 Jul 2019 12:57:51 +0000
> > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
> >
> > Lisp Backtrace:
> > "sleep-for" (0xedf7a530)
> > 0xf6da40 Lisp type 3
> >
> > post_acquire_global_lock () can return abnormally (I didn't know
> > that), so really_call_select() can, too, so thread_select() can, too.
>
> Do you know which code sets current_thread->error_symbol, and what is
> that error symbol?

thread-signal, which my example code calls directly. I passed 'error,
and that's what error_symbol is set to.

last_thread_error is (error) when the Emacs session freezes.

> > > > +  ptrdiff_t count = SPECPDL_INDEX ();
> > >
> > > I don't think we should do that at this low level.
> >
> > You're right, it does stick out. I think we're safe because we're
> > calling Fsignal with the global lock held, but it's not a pretty or
> > well-documented situation.
>
> Is this the main thread which does that?  if so, there should be no
> problem with holding the global lock in this case, is there?
>
> If this is not the main thread, then the error handlers should be set
> so as to log the error in last_thread_error, and then terminate the
> thread (via exiting the thread function, AFAIR).

Indeed, that's what happens; but the thread now fails to release the
GLib lock it had previously acquired, so other threads cannot acquire
it again, ever.

> If this is not what happens, I'd like to know what does happen here,
> and why.

Sure, we should understand what's going on here; even if the fix turns
out to be simple.