From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18438: 24.4.50; assertion failed in bidi.c Date: Sun, 19 Oct 2014 17:39:51 +0300 Message-ID: <83mw8scedk.fsf@gnu.org> References: <4745242cd3e424a6c4d5db0e8d3e33d0@amuri.net> <83h9zrlzc8.fsf@gnu.org> <54297FDB.6090606@cornell.edu> <837g0mmkf3.fsf@gnu.org> <6b19fab333f3d362ae61b30b299d7206@amuri.net> <83iok5ku74.fsf@gnu.org> <88ccbe34bf58322ae4b2a5657390c041@amuri.net> <83ppe1itu9.fsf@gnu.org> <837g08bdcy.fsf@gnu.org> <1c93d571dbd64d473e8c53ba59063425@amuri.net> <83k3416hlf.fsf@gnu.org> <02fd9e39e5724b113eb47ecef0408ae5@amuri.net> <83mw8w4gp6.fsf@gnu.org> <543FC3F6.9010101@cornell.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413729686 18158 80.91.229.3 (19 Oct 2014 14:41:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 14:41:26 +0000 (UTC) Cc: 18438@debbugs.gnu.org, aidalgol@amuri.net To: Ken Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 19 16:41:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XfrfZ-0007yg-RM for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Oct 2014 16:41:17 +0200 Original-Received: from localhost ([::1]:40268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfrfZ-0001kM-EF for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Oct 2014 10:41:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfrfR-0001kD-DQ for bug-gnu-emacs@gnu.org; Sun, 19 Oct 2014 10:41:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XfrfM-0003tr-6E for bug-gnu-emacs@gnu.org; Sun, 19 Oct 2014 10:41:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfrfM-0003tn-2V for bug-gnu-emacs@gnu.org; Sun, 19 Oct 2014 10:41:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XfrfL-0001xW-MD for bug-gnu-emacs@gnu.org; Sun, 19 Oct 2014 10:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Oct 2014 14:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18438 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 18438-submit@debbugs.gnu.org id=B18438.14137296187459 (code B ref 18438); Sun, 19 Oct 2014 14:41:03 +0000 Original-Received: (at 18438) by debbugs.gnu.org; 19 Oct 2014 14:40:18 +0000 Original-Received: from localhost ([127.0.0.1]:55879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xfreb-0001wE-5E for submit@debbugs.gnu.org; Sun, 19 Oct 2014 10:40:17 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:53222) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XfreU-0001vv-5S for 18438@debbugs.gnu.org; Sun, 19 Oct 2014 10:40:12 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NDP00B004I5J400@mtaout27.012.net.il> for 18438@debbugs.gnu.org; Sun, 19 Oct 2014 17:34:55 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDP004IR4I7R760@mtaout27.012.net.il>; Sun, 19 Oct 2014 17:34:55 +0300 (IDT) In-reply-to: <543FC3F6.9010101@cornell.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94770 > Date: Thu, 16 Oct 2014 09:11:18 -0400 > From: Ken Brown > CC: 18438@debbugs.gnu.org > > On 10/16/2014 3:27 AM, Eli Zaretskii wrote: > > Let's try to get a couple more full backtraces like this one, in case > > some pattern emerges that could give us some ideas. > > I saw some things in Thread 7 (the Windows message queue thread), especially > frame #14, which got me to look at the code for w32_wnd_proc in w32fns.c. The > code is about 1300 lines long, and includes several comments about why it is > thread-safe. Here are a few examples: > > Walking the frame list in this thread is safe (as long as > writes of Lisp_Object slots are atomic, which they are on Windows). > > It is also safe to use functions that make GDI calls, such as > w32_clear_rect, because these functions must obtain a DC handle > from the frame struct using get_frame_dc which is thread-aware. > > The code below does something that one shouldn't do: it > accesses the window object from a separate thread, while the > main (a.k.a. "Lisp") thread runs and can legitimately delete > and even GC it. That is why we are extra careful... > > I wonder if something in these 1300 lines is not thread-safe on Cygwin. For > example, I don't know if it's true on Cygwin that "writes of Lisp_Object slots > are atomic". I couldn't find even one "write to Lisp_Object slot" in that function, so I don't see how this would matter. Besides, the code that crashes has no relation to any Lisp objects: we are walking the buffer text there. So even if w32_wnd_proc does do something that's "verboten" with Lisp objects, I still don't see how that could change the result of a comparison-and-jump pair of instructions in mid-flight. The rest of what the comments in w32_wnd_proc say is correct, but again unrelated, for the same reasons. In fact, I cannot explain to myself at all how _any_ code that is not thread-safe could cause such a phenomenon. I can think of no other explanations for what we see except some code that somehow modifies the CPU flags between the compare instruction and the following jump instruction. Otherwise, how can it be that the value is valid, but Emacs still aborts? Any other ideas?