unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: 56487@debbugs.gnu.org
Subject: bug#56487: xgselect race condition leading to abort when USE_GTK not defined
Date: Sun, 10 Jul 2022 14:05:58 -0700	[thread overview]
Message-ID: <CA+G3_PM8-aF+OdLrBg+PPFOmvCMYcVr-VHsASRt0xe4b9E5FYQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

There is a race condition in xgselect.c leading to an abort being
raised in glib code. I have attached a patch that fixes the issue.

It took an absurd amount of time to track this down and debug. The
patch and repro file contain more information.

This is not the easiest bug to test for because the race condition is
non-deterministic, I have attached the elisp file that I use to
explore and reproduce the issue.

Ensure that you have glib installed and that you are building --with-x
so that the code in xgselect is enabled. Run configure as ./configure
--with-x-toolkit=lucid (or anything except gtk), and then run make.

Assuming process-thread-bugs.el is in the top level of the emacs repo
define the following function

function loop-abort () { while true; do src/emacs -Q -batch -l \
./process-thread-bugs.el will abort 1 || return $?; done }

You can then run loop-abort; echo $? and when the patch is not applied
Emacs will eventually abort. You can also add a call to fputs in
thread.c at the location of the comment and you will almost
immediately see the abort behavior, even when building with gtk.

[-- Attachment #2: 0001-xgselect.c-avoid-race-condition-leading-to-abort.patch --]
[-- Type: application/x-patch, Size: 5090 bytes --]

[-- Attachment #3: process-thread-bugs.el --]
[-- Type: application/x-lisp, Size: 9459 bytes --]

             reply	other threads:[~2022-07-10 21:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-10 21:05 Tom Gillespie [this message]
2022-07-11  1:53 ` bug#56487: xgselect race condition leading to abort when USE_GTK not defined Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11  2:50   ` Tom Gillespie
2022-07-11  3:13     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11  3:40       ` Tom Gillespie
2022-07-11 10:16         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 16:09           ` Tom Gillespie
2022-07-12  2:03             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-12  2:20               ` Tom Gillespie
2022-07-12 12:44                 ` Eli Zaretskii
2022-07-15  5:09                   ` Tom Gillespie
2023-09-07 18:30                   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+G3_PM8-aF+OdLrBg+PPFOmvCMYcVr-VHsASRt0xe4b9E5FYQ@mail.gmail.com \
    --to=tgbugs@gmail.com \
    --cc=56487@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).