GNU bug report logs - #25247
26.0.50; Concurrency crashes

Previous Next

Full log

Message #20 received at 25247 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: 25247 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#25247: 26.0.50; Concurrency crashes
Date: Fri, 23 Dec 2016 12:04:29 +0200

> From: Ken Raeburn <raeburn <at> raeburn.org>
> Date: Fri, 23 Dec 2016 04:34:12 -0500
> Cc: Tino Calancha <tino.calancha <at> gmail.com>,
>  25247 <at> debbugs.gnu.org
> 
> > It doesn't crash or hang here.  Which is not surprising, since the
> > backtraces seem to indicate some issue with X11/xcb and threads.  Ken,
> > could you take a look, please?  Are we violating some X11 protocols by
> > calling redisplay from different threads?
> 
> The documentation for XInitThreads, mentioned in one of the error messages, says it needs to be called before any other Xlib functions if a single display object might be used concurrently from multiple threads.

Yes, I've seen these as well.

> I’m testing out a change, but thus far haven’t been able to reproduce any of the crashes even without the patch, although I did run into the unblock_input_to abort on the concurrency branch, with a similar test program from Elias Mårtenson.

The problems with unblock_input_to should no longer happen on master,
where I installed a fix in xgselect.c to prevent a thread from
accessing the Glib context if it failed to acquire that context.  The
code which could cause several threads to call block_input and
unblock_input, thus stomping on each other's toes, is conditioned on
acquiring the Glib context, so I expected that not to be a problem
anymore.  However, one of the crashes reported by Tino still indicate
that problem exists somehow, because one of the crashes is abort in
unblock_input_to.

> Also, in looking into this, I found a couple vague references about how “it is known” that there are problems with the concurrency support in Xlib in some areas.  Unfortunately there were no details (not even clear if it was an Xlib problem or related to using Java classes that talk to Xlib in ways the developer might not fully control), and I’ll be busy the next few days.  I’ll try to find out more next week.  But if only one thread is talking to a given X display *at a time* (whether displays are assigned to specific threads, or locking is used, or only one thread uses X at all, or whatever), I haven’t seen anything so far that would suggest there would be any problem.

The last crash reported by Tino here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25247#11

shows an X error even though the non-primary threads don't do any
display.  See the backtrace for the primary thread (the last one) in
that message.  So there could be more than one problem here, and GTK
seems to be involved.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.