From: Tom Gillespie <tgbugs@gmail.com>
To: Po Lu <luangruo@yahoo.com>
Cc: 56487@debbugs.gnu.org
Subject: bug#56487: xgselect race condition leading to abort when USE_GTK not defined
Date: Sun, 10 Jul 2022 20:40:43 -0700 [thread overview]
Message-ID: <CA+G3_PPBPD-sM2Trtw0818wX=VfCU2ULTV+25TVuKh1t1Qouvw@mail.gmail.com> (raw)
In-Reply-To: <87v8s4z6in.fsf@yahoo.com>
> Thanks. Why did the code previously under !USE_GTK have to be removed?
When the !USE_GTK code is used an abort in glib will happen
stochastically due to an out-of-sync call to release_select_lock
in thread.c. This happens on my system somewhere between
approximately 1 in 10 and 1 in 10000 times that the test file
is run.
As far as I can tell from testing there is no difference in behavior
between the USE_GTK and !USE_GTK code. Also, as far as
I can tell from reading, the behavior should be almost identical.
The only addition is to check for already_has_events before
calling thread_select, which may be enough to shift the timing
to prevent a race.
I have not been able to figure out what the actual underlying
cause is (I tried). All I can say for sure is that there is
something that calls into g_main_context_release and
context->owner_count has a negative overflow to 4294967295.
I do not think that it is because something somehow sneaks
in between the calls to the atomics in acquire_select_lock
and relese_select_lock. If you would like I can send along
a couple of patches that include changes I made to try to
see what is going on.
The real underlying issue would seem to be that there is a
missing lock somewhere and that the use of atomics is not
sufficient, but I could be wrong about that.
next prev parent reply other threads:[~2022-07-11 3:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-10 21:05 bug#56487: xgselect race condition leading to abort when USE_GTK not defined Tom Gillespie
2022-07-11 1:53 ` 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+G3_PPBPD-sM2Trtw0818wX=VfCU2ULTV+25TVuKh1t1Qouvw@mail.gmail.com' \
--to=tgbugs@gmail.com \
--cc=56487@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.