From unknown Fri Aug 15 04:03:04 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#13007 <13007@debbugs.gnu.org> To: bug#13007 <13007@debbugs.gnu.org> Subject: Status: 24.3.50; emacs_backtrace.txt Reply-To: bug#13007 <13007@debbugs.gnu.org> Date: Fri, 15 Aug 2025 11:03:04 +0000 retitle 13007 24.3.50; emacs_backtrace.txt reassign 13007 emacs submitter 13007 "Drew Adams" severity 13007 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 01:25:49 2012 Received: (at submit) by debbugs.gnu.org; 27 Nov 2012 06:25:49 +0000 Received: from localhost ([127.0.0.1]:40886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdEc8-0005hf-LU for submit@debbugs.gnu.org; Tue, 27 Nov 2012 01:25:49 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44960) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdEc6-0005hX-3q for submit@debbugs.gnu.org; Tue, 27 Nov 2012 01:25:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdEaM-0005j6-0m for submit@debbugs.gnu.org; Tue, 27 Nov 2012 01:23:59 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:53277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdEaL-0005j0-Tf for submit@debbugs.gnu.org; Tue, 27 Nov 2012 01:23:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdEaK-0002rQ-NF for bug-gnu-emacs@gnu.org; Tue, 27 Nov 2012 01:23:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdEaJ-0005ik-Gf for bug-gnu-emacs@gnu.org; Tue, 27 Nov 2012 01:23:56 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:31850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdEaJ-0005ic-AR for bug-gnu-emacs@gnu.org; Tue, 27 Nov 2012 01:23:55 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAR6Nrd0017548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Nov 2012 06:23:54 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAR6Nri4019840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Nov 2012 06:23:53 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAR6NqGo009292 for ; Tue, 27 Nov 2012 00:23:53 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Nov 2012 22:23:52 -0800 From: "Drew Adams" To: Subject: 24.3.50; emacs_backtrace.txt Date: Mon, 26 Nov 2012 22:23:50 -0800 Message-ID: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3MZ8OiAXFvco6vTLiUxBPArNIJxA== X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) In case it helps, here is an emacs_backtrace.txt. AFAIK, I wasn't doing anything particular at the moment (usual use), and I had started Emacs only about 30 sec before the crash. Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012072B8 0x012080B9 0x0103B54F 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01208B6F 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01271987 0x012753CF 0x01201334 0x01202410 0x0121160D 0x01208C14 0x01010FC6 0x01208BA1 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x010EFEEA 0x010F6A68 0x010F5208 0x010F48F4 0x010F4616 0x0120710E 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01250F9C 0x01019E58 0x0105A84F 0x01014EFC 0x010E117F 0x010E0546 0x010132B0 0x01010DFC 0x010E1DBC 0x01015E7E 0x01015317 0x01014685 0x0103A4F4 0x01010EDE 0x0103A912 0x0101457A 0x0103A966 0x0103910E 0x01010EDE 0x0103800B 0x0101093B 0x01037F74 0x0103757F 0x010BE6ED 0x010BF3F7 0x01015217 0x010E117F 0x01015A23 0x01015317 0x010C1764 0x010152CD 0x010E117F 0x01015A23 0x01015317 0x010E117F 0x01015A23 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x010E0546 0x010132B0 0x01012901 0x010E4D6B 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-26 on MS-W7-DANI Bzr revision: 111014 monnier@iro.umontreal.ca-20121126195614-fwcm2hg6vt2fcn24 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include' From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 01:30:20 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 06:30:21 +0000 Received: from localhost ([127.0.0.1]:40892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdEgR-0005rU-Ki for submit@debbugs.gnu.org; Tue, 27 Nov 2012 01:30:18 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:32481) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdEgP-0005rN-2H for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 01:30:14 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAR6SOp5004177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <13007@debbugs.gnu.org>; Tue, 27 Nov 2012 06:28:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAR6SOpC012800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <13007@debbugs.gnu.org>; Tue, 27 Nov 2012 06:28:24 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAR6SNCV011776 for <13007@debbugs.gnu.org>; Tue, 27 Nov 2012 00:28:23 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Nov 2012 22:28:23 -0800 From: "Drew Adams" To: <13007@debbugs.gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Mon, 26 Nov 2012 22:28:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3MZ8OiAXFvco6vTLiUxBPArNIJxAAAEHyQ X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Started Emacs again, did the same thing, with my setup (tried to complete a file name for M-x load-file, as usual), and got another backtrace file. Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... I will stop using this build and return to the previous Windows build available. Cannot use this one at all. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 10:16:52 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 15:16:52 +0000 Received: from localhost ([127.0.0.1]:41836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdMu3-0004BG-FW for submit@debbugs.gnu.org; Tue, 27 Nov 2012 10:16:52 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:43047) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdMu0-0004B7-G1 for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 10:16:49 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ME500K00JMIIP00@a-mtaout22.012.net.il> for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 17:13:48 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME500J0VJMZQY80@a-mtaout22.012.net.il>; Tue, 27 Nov 2012 17:13:47 +0200 (IST) Date: Tue, 27 Nov 2012 17:14:02 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , Dmitry Antipov Message-id: <83k3t7xemd.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Mon, 26 Nov 2012 22:23:50 -0800 > > In case it helps, here is an emacs_backtrace.txt. AFAIK, I wasn't doing > anything particular at the moment (usual use), and I had started Emacs > only about 30 sec before the crash. Thanks, it does help. The backtrace produced by addr2line is below. The crash is due to assertion violation here: static int window_outdated (struct window *w) { eassert (XBUFFER (w->buffer) == current_buffer); <<<<<<<<<<<<<<<<<< return (w->last_modified < MODIFF || w->last_overlay_modified < OVERLAY_MODIFF); } Dmitry, why did you add this assertion? What code that you introduced assumes that this condition is always true? I suspect that we need to change this assertion to eassert (MINI_WINDOW_P (w) || w->pseudo_window_p || XBUFFER (w->buffer) == current_buffer); At least in this case (see the backtrace below), window_outdated is called from code that handles minibuffer windows, so I'm guessing the above assertion is not true. Here's the full backtrace: w32_backtrace at C:\emacs\trunk\src/w32fns.c:7735 emacs_abort at C:\emacs\trunk\src/w32fns.c:7767 terminate_due_to_signal at C:\emacs\trunk\src/emacs.c:341 die at C:\emacs\trunk\src/alloc.c:6487 window_outdated at C:\emacs\trunk\src/xdisp.c:10906 redisplay_internal at C:\emacs\trunk\src/xdisp.c:13213 redisplay at C:\emacs\trunk\src/xdisp.c:12715 read_char at C:\emacs\trunk\src/keyboard.c:2416 read_filtered_event at C:\emacs\trunk\src/lread.c:609 Fread_event at C:\emacs\trunk\src/lread.c:721 Ffuncall at C:\emacs\trunk\src/eval.c:2678 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 apply1 at C:\emacs\trunk\src/eval.c:2432 Fcall_interactively at C:\emacs\trunk\src/callint.c:377 Ffuncall at C:\emacs\trunk\src/eval.c:2678 call3 at C:\emacs\trunk\src/eval.c:2496 Fcommand_execute at C:\emacs\trunk\src/keyboard.c:10214 command_loop_1 at C:\emacs\trunk\src/keyboard.c:1576 internal_condition_case at C:\emacs\trunk\src/eval.c:1192 command_loop_2 at C:\emacs\trunk\src/keyboard.c:1163 internal_catch at C:\emacs\trunk\src/eval.c:963 command_loop at C:\emacs\trunk\src/keyboard.c:1134 recursive_edit_1 at C:\emacs\trunk\src/keyboard.c:774 read_minibuf at C:\emacs\trunk\src/minibuf.c:678 Fread_from_minibuffer at C:\emacs\trunk\src/minibuf.c:980 Ffuncall at C:\emacs\trunk\src/eval.c:2697 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 eval_sub at C:\emacs\trunk\src/eval.c:2042 internal_catch at C:\emacs\trunk\src/eval.c:963 exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2837 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 eval_sub at C:\emacs\trunk\src/eval.c:2042 internal_catch at C:\emacs\trunk\src/eval.c:963 exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 10:18:04 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 15:18:05 +0000 Received: from localhost ([127.0.0.1]:41841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdMvE-0004DZ-IG for submit@debbugs.gnu.org; Tue, 27 Nov 2012 10:18:04 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:49842) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdMvC-0004DO-Sx for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 10:18:03 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0ME500K00JP8J800@a-mtaout21.012.net.il> for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 17:15:11 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME500K6FJPA5B80@a-mtaout21.012.net.il>; Tue, 27 Nov 2012 17:15:11 +0200 (IST) Date: Tue, 27 Nov 2012 17:15:25 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83ip8rxek2.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Mon, 26 Nov 2012 22:28:21 -0800 > > Started Emacs again, did the same thing, with my setup (tried to > complete a file name for M-x load-file, as usual), and got another > backtrace file. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Mon, 26 Nov 2012 22:28:21 -0800 > > Started Emacs again, did the same thing, with my setup (tried to > complete a file name for M-x load-file, as usual), and got another > backtrace file. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4717] > From: "Drew Adams" > Date: Mon, 26 Nov 2012 22:28:21 -0800 > > Started Emacs again, did the same thing, with my setup (tried to > complete a file name for M-x load-file, as usual), and got another > backtrace file. So the abort happens when you are doing minibuffer input, or when some message is displayed in the echo area, is that right? Can you describe the configuration of frames and windows at the moment of the abort? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 10:43:40 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 15:43:40 +0000 Received: from localhost ([127.0.0.1]:41853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdNJz-0004pY-4O for submit@debbugs.gnu.org; Tue, 27 Nov 2012 10:43:39 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35242) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdNJu-0004pO-Ep for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 10:43:35 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qARFfhkg011830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 15:41:44 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qARFfhEV017531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 15:41:43 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qARFfg7N022711; Tue, 27 Nov 2012 09:41:42 -0600 Received: from dradamslap1 (/10.159.133.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Nov 2012 07:41:42 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83ip8rxek2.fsf@gnu.org> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Tue, 27 Nov 2012 07:41:39 -0800 Message-ID: <8C1CF8F9FC1C4C8586F9871324ECC3C6@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83ip8rxek2.fsf@gnu.org> Thread-Index: Ac3MsiRepwiZGWn7TDKVNDI/DaPAWAAAmMnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.6 (----) > > Started Emacs again, did the same thing, with my setup (tried to > > complete a file name for M-x load-file, as usual), and got another > > backtrace file. > > So the abort happens when you are doing minibuffer input, or when some > message is displayed in the echo area, is that right? Yes. I did (in my setup - standalone minibuffer, Icicles, etc.): M-x load-file icicles-ma TAB to complete to icicles-mac.el[c] > Can you describe the configuration of frames and windows at the moment > of the abort? 3 frames: 1. Dired (could be a file buffer or anything else) 2. Standalone minibuffer frame 3. *Completions* frame, showing the two candidates: icicles-mac.el icicles-mac-elc Immediately after starting Emacs (in Dired), I did the above `M-x'. TAB causes these things to happen, which I can see happened before the abort dialog appeared: a. Displays *Completions*, as mentioned above. b. Completes minibuffer input to c:/my/path/icicles-mac.el, and highlights the icicles-mac.el part to show that it is complete. The Emacs Abort Dialog says the usual (new text). HTH. In case there were minor differences from the original backtrace context, here is another backtrace file, from repeating exactly the recipe given above: Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 10:46:18 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 15:46:18 +0000 Received: from localhost ([127.0.0.1]:41868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdNMX-0004u2-PK for submit@debbugs.gnu.org; Tue, 27 Nov 2012 10:46:18 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:37231) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdNMU-0004tu-VP for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 10:46:16 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qARFiO5N015519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 15:44:25 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qARFiOcR023385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 15:44:24 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qARFiNLP002374; Tue, 27 Nov 2012 09:44:23 -0600 Received: from dradamslap1 (/10.159.133.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Nov 2012 07:44:23 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com><83ip8rxek2.fsf@gnu.org> <8C1CF8F9FC1C4C8586F9871324ECC3C6@us.oracle.com> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Tue, 27 Nov 2012 07:44:20 -0800 Message-ID: <83B6C5DBB8FD4C87916A5F021CEDF324@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <8C1CF8F9FC1C4C8586F9871324ECC3C6@us.oracle.com> Thread-Index: Ac3MsiRepwiZGWn7TDKVNDI/DaPAWAAAmMnQAABbncA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 3. *Completions* frame, showing the two candidates: > icicles-mac.el icicles-mac-elc ^^^^^^^^^^^^^^^ I meant icicles-mac.elc. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 11:42:14 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 16:42:14 +0000 Received: from localhost ([127.0.0.1]:41917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdOEf-0006F5-BW for submit@debbugs.gnu.org; Tue, 27 Nov 2012 11:42:13 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:63277) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdOEc-0006Ew-Fr for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 11:42:11 -0500 Received: by mail-ea0-f172.google.com with SMTP id a1so4611991eaa.3 for <13007@debbugs.gnu.org>; Tue, 27 Nov 2012 08:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AdJCVqY83bO2kU1STuv9NdUCFIHPfay3EvV+MpUiklk=; b=ZQNuDWXUiSe/3vdGru1alMMQ3CenykAGw3TbHQco41UxfomraS7kaHXrjoCw3P5WlX y3RNtiWrk+BOLGnBOu6w2LL6KTNaI8uv55inSW3w+3UhJG78XV41+jvey+ku9D/6wUx5 +Y0XkJJWbbK1DJi2CLsVrz4smpNRH/GgtPE30RDu/0RpkMucfyGhWoMoGHg4pWuF329X U2wvOZQcxjf3WvbzDMyMJVmu/p3Jvkv2txpSGHTzE/BuKJ4TsOhrTj3zXa2WLOkIIB5r Kh+cOyfmFtoApUkJH79xsb8cBY8a4Bp/fiHHNyXM7Pv/J35dj2z4rYhtiDgtChFwCnpc M+XQ== Received: by 10.14.210.200 with SMTP id u48mr59144742eeo.29.1354034418945; Tue, 27 Nov 2012 08:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Tue, 27 Nov 2012 08:39:38 -0800 (PST) In-Reply-To: <83ip8rxek2.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83ip8rxek2.fsf@gnu.org> From: Juanma Barranquero Date: Tue, 27 Nov 2012 17:39:38 +0100 Message-ID: Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii wrote: > So the abort happens when you are doing minibuffer input, or when some > message is displayed in the echo area, is that right? > > Can you describe the configuration of frames and windows at the moment > of the abort? I (having missed this bug thread, sorry) just filed bug#13012 with an easy recipe for the assertion failure. Feel free to merge both reports. Juanma From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 11:44:20 2012 Received: (at control) by debbugs.gnu.org; 27 Nov 2012 16:44:20 +0000 Received: from localhost ([127.0.0.1]:41927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdOGh-0006JF-Vx for submit@debbugs.gnu.org; Tue, 27 Nov 2012 11:44:20 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:36904) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdOGg-0006J9-5H for control@debbugs.gnu.org; Tue, 27 Nov 2012 11:44:18 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1TdOEu-0004Ny-Kr for control@debbugs.gnu.org; Tue, 27 Nov 2012 11:42:28 -0500 Date: Tue, 27 Nov 2012 11:42:28 -0500 Message-Id: Subject: control message for bug 13012 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.6 (----) merge 13007 13012 From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 11:51:17 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 16:51:17 +0000 Received: from localhost ([127.0.0.1]:41932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdONQ-0007LL-VG for submit@debbugs.gnu.org; Tue, 27 Nov 2012 11:51:17 -0500 Received: from forward2.mail.yandex.net ([77.88.46.7]:60378) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdONN-0007L6-3r for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 11:51:15 -0500 Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward2.mail.yandex.net (Yandex) with ESMTP id 9A4C812A15A6; Tue, 27 Nov 2012 20:49:21 +0400 (MSK) Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id 61DFC1BA079C; Tue, 27 Nov 2012 20:49:21 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id nKl87f0h-nLl8GFUE; Tue, 27 Nov 2012 20:49:21 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354034961; bh=a4i+g8Nz/xg8Yp78kuAIR6dHfbJHtzQ+OXQlZpBhwPU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sLgU/cMzqffSI6xgGZf+bZyUII+GndZ52XTRucGAMdZf4AuIoa2P5/8EWF3SKAUYw vLob51o21a/4YDdP/ayOK5t1Y1X5aoH3CBykIjCew8GgWCBCjZroGfj1xyKTjjOhEO uPis1gUbbbbZs3MydRdR71O/cM1btM8JXtNWcZsg= Message-ID: <50B4EF28.6040905@yandex.ru> Date: Tue, 27 Nov 2012 20:49:44 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> In-Reply-To: <83k3t7xemd.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 11/27/2012 07:14 PM, Eli Zaretskii wrote: > The crash is due to assertion violation here: > > static int > window_outdated (struct window *w) > { > eassert (XBUFFER (w->buffer) == current_buffer); <<<<<<<<<<<<<<<<<< > return (w->last_modified < MODIFF > || w->last_overlay_modified < OVERLAY_MODIFF); > } > > Dmitry, why did you add this assertion? What code that you introduced > assumes that this condition is always true? This eassert was installed just to trap on the suspicious use cases as we found in this bug :-). > I suspect that we need to change this assertion to > > eassert (MINI_WINDOW_P (w) || w->pseudo_window_p > || XBUFFER (w->buffer) == current_buffer); > > At least in this case (see the backtrace below), window_outdated is > called from code that handles minibuffer windows, so I'm guessing the > above assertion is not true. Hm... this really helps to bypass eassert, but: 1) is it meaningful to compare w->last_modified of minibuffer window with MODIFF? Shouldn't we compare it against BUFF_MODIFF of appropriate minibuffer? 2) is it possible to have an overlay in a minibuffer? 3) should window_outdated_p be applicable to pseudowindows at all? Dmitry From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 12:50:08 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 17:50:08 +0000 Received: from localhost ([127.0.0.1]:41992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPIO-0001Ad-9X for submit@debbugs.gnu.org; Tue, 27 Nov 2012 12:50:08 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:42175) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPIL-0001AU-0H for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 12:50:06 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ME500L00QM5FP00@a-mtaout20.012.net.il> for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 19:47:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME500KDEQQXH6M0@a-mtaout20.012.net.il>; Tue, 27 Nov 2012 19:47:22 +0200 (IST) Date: Tue, 27 Nov 2012 19:47:36 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <50B4EF28.6040905@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <834nkbx7if.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Tue, 27 Nov 2012 20:49:44 +0400 > From: Dmitry Antipov > CC: Drew Adams , 13007@debbugs.gnu.org > > 1) is it meaningful to compare w->last_modified of minibuffer window with > MODIFF? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4735] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Tue, 27 Nov 2012 20:49:44 +0400 > From: Dmitry Antipov > CC: Drew Adams , 13007@debbugs.gnu.org > > 1) is it meaningful to compare w->last_modified of minibuffer window with > MODIFF? I don't know. The old code did exactly that. > 2) is it possible to have an overlay in a minibuffer? Yes, definitely. E.g., icomplete-mode does that, AFAIR. > 3) should window_outdated_p be applicable to pseudowindows at all? I don't know. Do you want more crashes to be sure? ;-) From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 12:57:28 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 17:57:28 +0000 Received: from localhost ([127.0.0.1]:42009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPPU-0001LD-8x for submit@debbugs.gnu.org; Tue, 27 Nov 2012 12:57:28 -0500 Received: from mail-da0-f44.google.com ([209.85.210.44]:58455) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPPQ-0001L4-FB for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 12:57:25 -0500 Received: by mail-da0-f44.google.com with SMTP id z20so2678971dae.3 for <13007@debbugs.gnu.org>; Tue, 27 Nov 2012 09:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=ZBcEsxdx9M/er4gOkHk0YTg/nR7TyjTaI3FS21IdB0A=; b=RD6zdlGWttcA7ekZkSAL+OEEzwzG6BRdIYh1BKci0XnM/vGUpA7qIi8VnWX5Hpz+7J R+UtAgLaVN2byy7cgK07ybNo01r9vIzvoZ03sTtfsbFzs2enUBvPwvazLmJEonKVJj6c yNhPw+cKQa59o3qRfuKLXi/+6XJ7PJpsEwpnCTj4xoY37Akw3rG0q9csmqNpeWcBWV5j wclE6YxucBSTxuEBOm4riDfqLkhs+4E1Mjyv5Z5I9vXI9DD77Qjbg/i5LDEl/RJsc702 1dLjxFaWKexw2/fhKCF71sd+W4iqAlH3eJgRG2jERT+Kzau3146kYdn2oQMe351XztjP tF7g== Received: by 10.68.130.197 with SMTP id og5mr49897951pbb.138.1354038934047; Tue, 27 Nov 2012 09:55:34 -0800 (PST) Received: from debian-6.05 ([115.184.83.157]) by mx.google.com with ESMTPS id x6sm11003944pav.29.2012.11.27.09.55.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 09:55:33 -0800 (PST) From: Jambunathan K To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> Date: Tue, 27 Nov 2012 23:28:00 +0530 In-Reply-To: <834nkbx7if.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Nov 2012 19:47:36 +0200") Message-ID: <877gp70vyv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, Dmitry Antipov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) Eli Zaretskii writes: >> 2) is it possible to have an overlay in a minibuffer? > > Yes, definitely. E.g., icomplete-mode does that, AFAIR. minibuffer.el does it as well. See `minibuffer-message'. Stuff like `[Sole completion]', `[No completions]' etc are really overlays. -- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 13:04:00 2012 Received: (at control) by debbugs.gnu.org; 27 Nov 2012 18:04:00 +0000 Received: from localhost ([127.0.0.1]:42017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPVn-0001VR-1H for submit@debbugs.gnu.org; Tue, 27 Nov 2012 13:04:00 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:59623) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPVl-0001VI-IT for control@debbugs.gnu.org; Tue, 27 Nov 2012 13:03:58 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0ME500K00R75W400@a-mtaout23.012.net.il> for control@debbugs.gnu.org; Tue, 27 Nov 2012 20:02:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME500KNMRFISM40@a-mtaout23.012.net.il> for control@debbugs.gnu.org; Tue, 27 Nov 2012 20:02:06 +0200 (IST) Date: Tue, 27 Nov 2012 20:02:21 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: X-012-Sender: halo1@inter.net.il To: control@debbugs.gnu.org Message-id: <83zk22x6tu.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83ip8rxek2.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 13012 13007 stop [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 13012 13007 stop [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4621] merge 13012 13007 stop From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 13:04:09 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 18:04:09 +0000 Received: from localhost ([127.0.0.1]:42022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPVx-0001WO-AC for submit@debbugs.gnu.org; Tue, 27 Nov 2012 13:04:09 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:59633) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPVv-0001WH-O8 for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 13:04:08 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0ME500K00R75W400@a-mtaout23.012.net.il> for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 20:02:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME500KP5RFSSM40@a-mtaout23.012.net.il>; Tue, 27 Nov 2012 20:02:17 +0200 (IST) Date: Tue, 27 Nov 2012 20:02:31 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <83y5hmx6tk.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83ip8rxek2.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Juanma Barranquero > Date: Tue, 27 Nov 2012 17:39:38 +0100 > Cc: Drew Adams , 13007@debbugs.gnu.org > > On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii wrote: > > > So the abort happens when you are doing minibuffer input, or when some > > message is displayed in the echo area, is that right? > > > > Can you describe the configuration of frames and windows at the moment > > of the abort? > > I (having missed this bug thread, sorry) just filed bug#13012 with an > easy recipe for the assertion failure. > > Feel free to merge both reports. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4823] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Juanma Barranquero > Date: Tue, 27 Nov 2012 17:39:38 +0100 > Cc: Drew Adams , 13007@debbugs.gnu.org > > On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii wrote: > > > So the abort happens when you are doing minibuffer input, or when some > > message is displayed in the echo area, is that right? > > > > Can you describe the configuration of frames and windows at the moment > > of the abort? > > I (having missed this bug thread, sorry) just filed bug#13012 with an > easy recipe for the assertion failure. > > Feel free to merge both reports. Done. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 27 13:12:36 2012 Received: (at 13007) by debbugs.gnu.org; 27 Nov 2012 18:12:36 +0000 Received: from localhost ([127.0.0.1]:42030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPe8-0001ia-1B for submit@debbugs.gnu.org; Tue, 27 Nov 2012 13:12:36 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:26140) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdPe5-0001iT-QV for 13007@debbugs.gnu.org; Tue, 27 Nov 2012 13:12:34 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qARIAg6g005901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 18:10:42 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qARIAfxs005158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 18:10:42 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qARIAfWW020084; Tue, 27 Nov 2012 12:10:41 -0600 Received: from dradamslap1 (/10.159.133.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Nov 2012 10:10:41 -0800 From: "Drew Adams" To: "'Jambunathan K'" , "'Eli Zaretskii'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com><83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru><834nkbx7if.fsf@gnu.org> <877gp70vyv.fsf@gmail.com> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Tue, 27 Nov 2012 10:10:37 -0800 Message-ID: <4A0D6F163C0449EB952B04814626A7B7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <877gp70vyv.fsf@gmail.com> Thread-Index: Ac3MyIMujxvjil1zQDaykSLEkfd8BQAAR6xw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, 'Dmitry Antipov' X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > >> 2) is it possible to have an overlay in a minibuffer? > > > > Yes, definitely. E.g., icomplete-mode does that, AFAIR. > > minibuffer.el does it as well. See `minibuffer-message'. > Stuff like `[Sole completion]', `[No completions]' etc are really > overlays. Yes, and more importantly, _user_ code can use overlays in the minibuffer (as in any other buffer, AFAIK). It is great to point _also_ to existing Emacs source code in this regard, but this is really inessential (irrelevant). What's important wrt overlays here is that users can create and use them, not that some existing Emacs code might do so. What users can do they will do. Emacs should do its best not to crash in such a context. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 28 02:21:12 2012 Received: (at 13007) by debbugs.gnu.org; 28 Nov 2012 07:21:12 +0000 Received: from localhost ([127.0.0.1]:42517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdbxG-000844-UO for submit@debbugs.gnu.org; Wed, 28 Nov 2012 02:21:12 -0500 Received: from forward3h.mail.yandex.net ([84.201.187.148]:39090) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdbxC-00083t-K2 for 13007@debbugs.gnu.org; Wed, 28 Nov 2012 02:21:09 -0500 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 5054E13607A5; Wed, 28 Nov 2012 11:19:07 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id D3F1E17000D1; Wed, 28 Nov 2012 11:19:06 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id J6OKhxw9-J6O8iLMh; Wed, 28 Nov 2012 11:19:06 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354087146; bh=FlOlefotg+muQaxfcvo3Rr7IrbqCUTl3advaQyJQ1Co=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=fL0oWqs5lMTSDAXVGDy7p/sjPmnPw0aSiEVpNwVNikYmtErx+ZdXc26oZLc3DugW4 BlXVZTnMlO1qK3gPgFPuxk/JhSuEtIFhmQfHhlmmIJz3HEltUeiH7lJAy5S3vWYxP3 7wulXX8+e4qZ39YBa5eDWMPfIlaucvpyCiPMU5tI= Message-ID: <50B5BB01.2070304@yandex.ru> Date: Wed, 28 Nov 2012 11:19:29 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: 13007@debbugs.gnu.org Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> In-Reply-To: <834nkbx7if.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------070706010705000106080705" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: Eli Zaretskii , drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) This is a multi-part message in MIME format. --------------070706010705000106080705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit IIUC crash is triggered by this fragment: 13212 else if (EQ (selected_window, minibuf_window) 13213 && (current_buffer->clip_changed || window_outdated (w)) 13214 && resize_mini_window (w, 0)) So selected_window is the same as minibuf_window, and w->buffer is not the same as current_buffer; but, is w equal to XWINDOW (selected_window) here? Look above: 13114 /* Notice any pending interrupt request to change frame size. */ 13115 do_pending_window_change (1); 13116 13117 /* do_pending_window_change could change the selected_window due to 13118 frame resizing which makes the selected window too small. */ 13119 if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) 13120 { 13121 sw = w; 13122 reconsider_clip_changes (w, current_buffer); 13123 } 13124 13125 /* Clear frames marked as garbaged. */ 13126 clear_garbaged_frames (); 13127 13128 /* Build menubar and tool-bar items. */ 13129 if (NILP (Vmemory_full)) 13130 prepare_menu_bars (); Here prepare_menu_bars can run Lisp and so change something. 13131 13132 if (windows_or_buffers_changed) 13133 update_mode_lines++; 13134 13135 /* Detect case that we need to write or remove a star in the mode line. */ 13136 if ((SAVE_MODIFF < MODIFF) != w->last_had_star) If we ran Lisp above, how we can be sure that w is still equal to XWINDOW (selected_window)? Can someone try this patch? Dmitry --------------070706010705000106080705 Content-Type: text/plain; charset=UTF-8; name="1.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="1.patch" PT09IG1vZGlmaWVkIGZpbGUgJ3NyYy94ZGlzcC5jJwotLS0gc3JjL3hkaXNwLmMJMjAxMi0x MS0yNyAwMzoxMDozMiArMDAwMAorKysgc3JjL3hkaXNwLmMJMjAxMi0xMS0yOCAwNzoxMzow NCArMDAwMApAQCAtMTA5MDMsNiArMTA5MDMsOSBAQAogc3RhdGljIGludAogd2luZG93X291 dGRhdGVkIChzdHJ1Y3Qgd2luZG93ICp3KQogeworICBpZiAody0+cHNldWRvX3dpbmRvd19w KQorICAgIC8qIEFsd2F5cyB1cGRhdGUgbWVudSBiYXIgd2luZG93cy4gICovCisgICAgcmV0 dXJuIDE7CiAgIGVhc3NlcnQgKFhCVUZGRVIgKHctPmJ1ZmZlcikgPT0gY3VycmVudF9idWZm ZXIpOwogICByZXR1cm4gKHctPmxhc3RfbW9kaWZpZWQgPCBNT0RJRkYgCiAJICB8fCB3LT5s YXN0X292ZXJsYXlfbW9kaWZpZWQgPCBPVkVSTEFZX01PRElGRik7CkBAIC0xMzExNCwxNCAr MTMxMTcsNiBAQAogICAvKiBOb3RpY2UgYW55IHBlbmRpbmcgaW50ZXJydXB0IHJlcXVlc3Qg dG8gY2hhbmdlIGZyYW1lIHNpemUuICAqLwogICBkb19wZW5kaW5nX3dpbmRvd19jaGFuZ2Ug KDEpOwogCi0gIC8qIGRvX3BlbmRpbmdfd2luZG93X2NoYW5nZSBjb3VsZCBjaGFuZ2UgdGhl IHNlbGVjdGVkX3dpbmRvdyBkdWUgdG8KLSAgICAgZnJhbWUgcmVzaXppbmcgd2hpY2ggbWFr ZXMgdGhlIHNlbGVjdGVkIHdpbmRvdyB0b28gc21hbGwuICAqLwotICBpZiAoV0lORE9XUCAo c2VsZWN0ZWRfd2luZG93KSAmJiAodyA9IFhXSU5ET1cgKHNlbGVjdGVkX3dpbmRvdykpICE9 IHN3KQotICAgIHsKLSAgICAgIHN3ID0gdzsKLSAgICAgIHJlY29uc2lkZXJfY2xpcF9jaGFu Z2VzICh3LCBjdXJyZW50X2J1ZmZlcik7Ci0gICAgfQotCiAgIC8qIENsZWFyIGZyYW1lcyBt YXJrZWQgYXMgZ2FyYmFnZWQuICAqLwogICBjbGVhcl9nYXJiYWdlZF9mcmFtZXMgKCk7CiAK QEAgLTEzMTI5LDYgKzEzMTI0LDE1IEBACiAgIGlmIChOSUxQIChWbWVtb3J5X2Z1bGwpKQog ICAgIHByZXBhcmVfbWVudV9iYXJzICgpOwogCisgIC8qIFJlc3luYyBiZWNhdXNlIHByZXBh cmVfbWVudV9iYXJzIG1heSBydW4gTGlzcCBvciBkb19wZW5kaW5nX3dpbmRvd19jaGFuZ2UK KyAgICAgY291bGQgY2hhbmdlIHRoZSBzZWxlY3RlZF93aW5kb3cgZHVlIHRvIGZyYW1lIHJl c2l6aW5nIHdoaWNoIG1ha2VzIHRoZQorICAgICBzZWxlY3RlZCB3aW5kb3cgdG9vIHNtYWxs LiAgKi8KKyAgaWYgKFdJTkRPV1AgKHNlbGVjdGVkX3dpbmRvdykgJiYgKHcgPSBYV0lORE9X IChzZWxlY3RlZF93aW5kb3cpKSAhPSBzdykKKyAgICB7CisgICAgICBzdyA9IHc7CisgICAg ICByZWNvbnNpZGVyX2NsaXBfY2hhbmdlcyAodywgY3VycmVudF9idWZmZXIpOworICAgIH0K KwogICBpZiAod2luZG93c19vcl9idWZmZXJzX2NoYW5nZWQpCiAgICAgdXBkYXRlX21vZGVf bGluZXMrKzsKIAoK --------------070706010705000106080705-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 28 08:11:44 2012 Received: (at 13007) by debbugs.gnu.org; 28 Nov 2012 13:11:44 +0000 Received: from localhost ([127.0.0.1]:42782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdhQW-00022Z-D1 for submit@debbugs.gnu.org; Wed, 28 Nov 2012 08:11:44 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:38247) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdhQV-00022T-DM for 13007@debbugs.gnu.org; Wed, 28 Nov 2012 08:11:43 -0500 Received: by mail-ea0-f172.google.com with SMTP id a1so4987827eaa.3 for <13007@debbugs.gnu.org>; Wed, 28 Nov 2012 05:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=34TjPamaqw7PvwRw7rgy8M2XjBBS+mYOteqURY6Ynr4=; b=lPDDNRH+g2sxV2OUNyKo7enKTa6wQpZkgu7z+vHZ12MWBkPMC+KcYR7VK0ldDWrbb5 C95OIS8Tr90FdRItm3D74rm+lHCSf5ICSr0/lTsdDoMAed/dxiYH9snI+AOTZKJE4Pd7 0Yyfl4jUu9m54pr48ORXzwIGbo+o9MBUp1V28drWEffCzy27MIlEkdx9VXA4A+/XsUkf TbVPQU0pUookR4Gi8ltWfLmuXtUMqFfgw/TbIkwpUFOVD0ZXk0chWdGE+Z01+cANFC7s DR4FPE74K9M1UuEpnaHAepVIkLaiWazJ1Fj2ys11CdDRToUhMPObAiMi+tojAS5Wte8S lVNQ== Received: by 10.14.210.200 with SMTP id u48mr68798889eeo.29.1354108188425; Wed, 28 Nov 2012 05:09:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Wed, 28 Nov 2012 05:09:08 -0800 (PST) In-Reply-To: <50B5BB01.2070304@yandex.ru> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> From: Juanma Barranquero Date: Wed, 28 Nov 2012 14:09:08 +0100 Message-ID: Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt To: Dmitry Antipov Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Wed, Nov 28, 2012 at 8:19 AM, Dmitry Antipov wrote: > Can someone try this patch? What result did you expect? In my use case, the assertion still fails. Juanma From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 28 10:53:45 2012 Received: (at 13007) by debbugs.gnu.org; 28 Nov 2012 15:53:45 +0000 Received: from localhost ([127.0.0.1]:43819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdjxI-0007j9-O4 for submit@debbugs.gnu.org; Wed, 28 Nov 2012 10:53:44 -0500 Received: from forward5.mail.yandex.net ([77.88.46.21]:60960) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdjxE-0007ix-B2 for 13007@debbugs.gnu.org; Wed, 28 Nov 2012 10:53:43 -0500 Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id 3FD6412017AB; Wed, 28 Nov 2012 19:51:43 +0400 (MSK) Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id EAD5F1BA03D6; Wed, 28 Nov 2012 19:51:42 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id pgl8tmqX-pglWXuCf; Wed, 28 Nov 2012 19:51:42 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354117902; bh=SrPMhDbyvjz8QKDpKQdT4LpF4XWaVQMmBDoUIZNCH94=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=eDs3nTdgS8Ff/1YPCzqCVoTWOAvUzs+sahGPuiN0fojvt0Gu6qX7EMwXBVCR51ELJ DjpgfeA2jvWP+biZStVZyUWFjTJB/a7ZUyGkTcRqgkK2fgrbCGAh9wPfD5DsmX5sIC FzlkAPZOu6oOyls3kr4Cmmz5VmJ+4iLQnZYkkWt8= Message-ID: <50B63309.1070404@yandex.ru> Date: Wed, 28 Nov 2012 19:51:37 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: 13007@debbugs.gnu.org Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050103090801070907080002" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: Juanma Barranquero , Eli Zaretskii , Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) This is a multi-part message in MIME format. --------------050103090801070907080002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/28/2012 05:09 PM, Juanma Barranquero wrote: > What result did you expect? In my use case, the assertion still fails. OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the corner case where XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer; this should be fixed by always examining window buffer instead of current. This should works for mini windows too, but I'm not 100% sure about pseudo windows. Drew, since I can't reproduce your crash, could you please a) try this patch and b) check whether window with non-zero pseudo_window_p field is passed to window_outdated_p? Dmitry --------------050103090801070907080002 Content-Type: text/plain; charset=UTF-8; name="2.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.patch" PT09IG1vZGlmaWVkIGZpbGUgJ3NyYy94ZGlzcC5jJwotLS0gc3JjL3hkaXNwLmMJMjAxMi0x MS0yNyAwMzoxMDozMiArMDAwMAorKysgc3JjL3hkaXNwLmMJMjAxMi0xMS0yOCAxNTozOTo1 NSArMDAwMApAQCAtMTA4OTgsMTQgKzEwODk4LDE3IEBACiB9CiAKIC8qIE5vbnplcm8gaWYg VyBkb2Vzbid0IHJlZmxlY3QgdGhlIGFjdHVhbCBzdGF0ZSBvZgotICAgY3VycmVudCBidWZm ZXIgZHVlIHRvIGl0cyB0ZXh0IG9yIG92ZXJsYXlzIGNoYW5nZS4gICovCisgICBpdHMgYnVm ZmVyIGR1ZSB0byBpdHMgdGV4dCBvciBvdmVybGF5cyBjaGFuZ2UuICAqLwogCiBzdGF0aWMg aW50CiB3aW5kb3dfb3V0ZGF0ZWQgKHN0cnVjdCB3aW5kb3cgKncpCiB7Ci0gIGVhc3NlcnQg KFhCVUZGRVIgKHctPmJ1ZmZlcikgPT0gY3VycmVudF9idWZmZXIpOwotICByZXR1cm4gKHct Pmxhc3RfbW9kaWZpZWQgPCBNT0RJRkYgCi0JICB8fCB3LT5sYXN0X292ZXJsYXlfbW9kaWZp ZWQgPCBPVkVSTEFZX01PRElGRik7CisgIHN0cnVjdCBidWZmZXIgKmIgPSBYQlVGRkVSICh3 LT5idWZmZXIpOworCisgIGVhc3NlcnQgKEJVRkZFUl9MSVZFX1AgKGIpKTsKKworICByZXR1 cm4gKHctPmxhc3RfbW9kaWZpZWQgPCBCVUZfTU9ESUZGIChiKQorCSAgfHwgdy0+bGFzdF9v dmVybGF5X21vZGlmaWVkIDwgQlVGX09WRVJMQVlfTU9ESUZGIChiKSk7CiB9CiAKIC8qIE5v bnplcm8gaWYgVydzIGJ1ZmZlciB3YXMgY2hhbmdlZCBidXQgbm90IHNhdmVkIG9yIFRyYW5z aWVudCBNYXJrIG1vZGUKCg== --------------050103090801070907080002-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 28 12:44:25 2012 Received: (at control) by debbugs.gnu.org; 28 Nov 2012 17:44:25 +0000 Received: from localhost ([127.0.0.1]:43940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdlgP-0002iN-5C for submit@debbugs.gnu.org; Wed, 28 Nov 2012 12:44:25 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:63186) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdlgJ-0002hz-LU for control@debbugs.gnu.org; Wed, 28 Nov 2012 12:44:21 -0500 Received: by mail-bk0-f44.google.com with SMTP id w11so6331223bku.3 for ; Wed, 28 Nov 2012 09:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4x9UQEKILUq6ZNeRjJg7tY/0oQGSvhL/vKCRGCWzRwI=; b=mouL9+3xzw7qL5DcGP/EaTL8ncUh4UuwqI7m3AF8KenF0ToZTc85rdY31IbS0ZAa3R g+F+qJpsTOn0Ji7XKf+8iXrxxI/CzewkLSMQhPa3KYtipCou7Ua5MI5FM7fwYwueEJhu QoCHyF+6k61+QfHSF3FXtikXR9FQBO0K+3op49NYe0os88nPUzWbqKKSKoSQgiQgyDAN 4B0P8iTDxhfDZUG2STgC/3YQfALwWD2dDd35jnkPEmQhDL1Dp0C0wqqN7Su/I+Ls90Vy 6oJfYiUGr//SiGCGBkZfOjWUwcrb+MkbDeuxpnAINl0u6Pg8URusUHlet0dmHhlsnYN/ EAgw== Received: by 10.205.129.17 with SMTP id hg17mr5937552bkc.41.1354124543566; Wed, 28 Nov 2012 09:42:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.34.70 with HTTP; Wed, 28 Nov 2012 09:41:42 -0800 (PST) In-Reply-To: <80sj7tu6sv.fsf@missioncriticalit.com> References: <80sj7tu6sv.fsf@missioncriticalit.com> From: Juanma Barranquero Date: Wed, 28 Nov 2012 18:41:42 +0100 Message-ID: Subject: Re: bug#13020: 24.3.50; assertion failed: XBUFFER (w->buffer) == current_buffer To: Fabrice Niessen Content-Type: text/plain; charset=UTF-8 Bcc: control@debbugs.gnu.org X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: control Cc: 13020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) merge 13007 13020 quit > Thread 1 (Thread 8020.0x17f4): > #0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll > #1 0x01154cc5 in emacs_abort () at w32fns.c:7761 > #2 0x0100145d in terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:341 > #3 0x010218ff in die (msg=0x15c59d0 "assertion failed: XBUFFER (w->buffer) == current_buffer", file=0x15be050 "xdisp.c", > line=10906) at alloc.c:6487 > #4 0x011fe680 in window_outdated (w=0x39c7990 <__register_frame_info+60586384>) at xdisp.c:10906 This is a duplicate of 13007 & 13012. Merged. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 28 13:01:55 2012 Received: (at 13007) by debbugs.gnu.org; 28 Nov 2012 18:01:55 +0000 Received: from localhost ([127.0.0.1]:43974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdlxL-00041A-4P for submit@debbugs.gnu.org; Wed, 28 Nov 2012 13:01:55 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:43665) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdlxI-000411-9J for 13007@debbugs.gnu.org; Wed, 28 Nov 2012 13:01:53 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ME700F00LWB5300@a-mtaout20.012.net.il> for 13007@debbugs.gnu.org; Wed, 28 Nov 2012 19:58:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME700E7HLY2KKD0@a-mtaout20.012.net.il>; Wed, 28 Nov 2012 19:58:51 +0200 (IST) Date: Wed, 28 Nov 2012 19:59:08 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <50B63309.1070404@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <838v9lwqvn.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 28 Nov 2012 19:51:37 +0400 > From: Dmitry Antipov > CC: Juanma Barranquero , > Drew Adams , > Eli Zaretskii > > OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the > corner case where XBUFFER (XWINDOW (selected_window)->buffer) != > current_buffer; this should be fixed by always examining window buffer > instead of current. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4011] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 28 Nov 2012 19:51:37 +0400 > From: Dmitry Antipov > CC: Juanma Barranquero , > Drew Adams , > Eli Zaretskii > > OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the > corner case where XBUFFER (XWINDOW (selected_window)->buffer) != > current_buffer; this should be fixed by always examining window buffer > instead of current. The display engine assumes that the buffer being rendered is current_buffer in a lot of places. If you want to use w->buffer instead, you will have to change many places, including those that don't receive a pointer to the window being redisplayed. (And there's the TTY redisplay which is frame-based, and doesn't necessarily go by windows in the first place.) Let me turn the table and ask why should we insist on this assertion? What do we gain by enforcing it? I know what we lose: the trunk is severely broken for 2 days, and counting. 3 people have independently bumped into this in 2 different situations. If there's no significant gain in this, I say let's remove the assertion and move on. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 01:21:59 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 06:22:00 +0000 Received: from localhost ([127.0.0.1]:44478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdxVX-0005j2-Au for submit@debbugs.gnu.org; Thu, 29 Nov 2012 01:21:59 -0500 Received: from forward5.mail.yandex.net ([77.88.46.21]:47736) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdxVS-0005iq-PQ for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 01:21:58 -0500 Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward5.mail.yandex.net (Yandex) with ESMTP id 25AA3120163D; Thu, 29 Nov 2012 10:19:54 +0400 (MSK) Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id C05B9E20309; Thu, 29 Nov 2012 10:19:53 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Jrmi3N58-JrmKINrU; Thu, 29 Nov 2012 10:19:53 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354169993; bh=MkZuurXr5+eUZwcBU8EFz216nhASWSjobAjEhgTo5XU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=u1mW/6rj/L1FiNegoSKIIYbwXgYYbI9+b4klNd+3OWLB56b2Pn4EiU/tPiuY7NvgS +zSbBSF2ILY3DLEnlPTmkpU/BH0WpaR+RwMaX7pN+DkJvvmkqIfVJO3JukAxnj7GkP 3006veCsA3ZqVBJxlkhgpKswm/izRMB/tmiGDdr8= Message-ID: <50B6FE89.20304@yandex.ru> Date: Thu, 29 Nov 2012 10:19:53 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> In-Reply-To: <838v9lwqvn.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 11/28/2012 09:59 PM, Eli Zaretskii wrote: > Let me turn the table and ask why should we insist on this assertion? > What do we gain by enforcing it? > > I know what we lose: the trunk is severely broken for 2 days, and > counting. 3 people have independently bumped into this in 2 different > situations. If there's no significant gain in this, I say let's > remove the assertion and move on. OK for now. But I still thinks that we just ignore some unusual cases which needs more investigations. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 11:48:41 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 16:48:41 +0000 Received: from localhost ([127.0.0.1]:45407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7I1-0004Ki-FM for submit@debbugs.gnu.org; Thu, 29 Nov 2012 11:48:41 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:33011) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7Hz-0004KY-M7 for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 11:48:40 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ME900600D6FVP00@a-mtaout20.012.net.il> for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 18:46:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME9006B4D9AEHB0@a-mtaout20.012.net.il>; Thu, 29 Nov 2012 18:46:22 +0200 (IST) Date: Thu, 29 Nov 2012 18:46:43 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <50B6FE89.20304@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83txs8uzkc.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 29 Nov 2012 10:19:53 +0400 > From: Dmitry Antipov > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/28/2012 09:59 PM, Eli Zaretskii wrote: > > > Let me turn the table and ask why should we insist on this assertion? > > What do we gain by enforcing it? > > > > I know what we lose: the trunk is severely broken for 2 days, and > > counting. 3 people have independently bumped into this in 2 different > > situations. If there's no significant gain in this, I say let's > > remove the assertion and move on. > > OK for now. But I still thinks that we just ignore some unusual cases > which needs more investigations. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4968] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Thu, 29 Nov 2012 10:19:53 +0400 > From: Dmitry Antipov > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/28/2012 09:59 PM, Eli Zaretskii wrote: > > > Let me turn the table and ask why should we insist on this assertion? > > What do we gain by enforcing it? > > > > I know what we lose: the trunk is severely broken for 2 days, and > > counting. 3 people have independently bumped into this in 2 different > > situations. If there's no significant gain in this, I say let's > > remove the assertion and move on. > > OK for now. But I still thinks that we just ignore some unusual cases > which needs more investigations. I'm okay with investigating, as long as others don't suffer too much. For starters, can you tell what triggered the assertion violation in Juanma's case? IOW, how did we wind up in a situation where (AFAIU) the selected window displays a buffer other than the current one? And Drew, could you please try coming up with a simple recipe starting with "emacs -Q"? If you define a configuration with a minibuffer-less frame, a separate minibuffer frame, and arrange for *Completions* to pop up yet another frame, then trigger completion in some simple way, does Emacs abort like in your original report? TIA From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 12:04:21 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 17:04:21 +0000 Received: from localhost ([127.0.0.1]:45413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7XA-0004hM-Ut for submit@debbugs.gnu.org; Thu, 29 Nov 2012 12:04:21 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:29640) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7X8-0004hE-Uy for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 12:04:19 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATH2F7U002356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 17:02:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qATH2EaO013259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 17:02:15 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qATH2E3w017279; Thu, 29 Nov 2012 11:02:14 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Nov 2012 09:02:14 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Dmitry Antipov'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Thu, 29 Nov 2012 09:02:13 -0800 Message-ID: <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <83txs8uzkc.fsf@gnu.org> Thread-Index: Ac3OURtXLkBLot7TRGOI5F3Da9o3ZwAAURmw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > And Drew, could you please try coming up with a simple recipe starting > with "emacs -Q"? If you define a configuration with a minibuffer-less > frame, a separate minibuffer frame, and arrange for *Completions* to > pop up yet another frame, then trigger completion in some simple way, > does Emacs abort like in your original report? No, I'm sorry Eli, I just don't have the time for that now. I have reverted to using the Emacs binary before these crashes were introduced. If you happen to make some progress then I will be glad to try the result and let you know the effect in my context. My guess (& hope) is that there is a good chance that Juanma and I were bitten by the same bug. If not, we can look into my case more later, when I have some more time. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 12:25:49 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 17:25:49 +0000 Received: from localhost ([127.0.0.1]:45455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7rx-0005CE-GN for submit@debbugs.gnu.org; Thu, 29 Nov 2012 12:25:49 -0500 Received: from forward19.mail.yandex.net ([95.108.253.144]:33075) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7rs-0005C2-Ow for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 12:25:48 -0500 Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward19.mail.yandex.net (Yandex) with ESMTP id 7A4371121872; Thu, 29 Nov 2012 21:23:39 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id 2E5FEBE02D5; Thu, 29 Nov 2012 21:23:39 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Nb9CdwaJ-Nc9aJorn; Thu, 29 Nov 2012 21:23:38 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354209819; bh=lyjQA2WUMwTktOq5yywQOR4llrXS9RpDQAJyd7EQ7SU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XywjvQ6JOKxAvmPA5L8To65UicLURw4SwCBeSiQHoE/SD45C/OHiIKjU6G3RV9ncB 1uhiLmI2U95hQx5+74ieBcxzIdALJduAuGg4x5ZE/9FAOc1QpQFLcDt5L8M7JPgPWZ NQHsiWNZrehlq+Wf8qOFzKCDlNE2dzfshgwuX+DU= Message-ID: <50B79A19.2050707@yandex.ru> Date: Thu, 29 Nov 2012 21:23:37 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> In-Reply-To: <83txs8uzkc.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 11/29/2012 08:46 PM, Eli Zaretskii wrote: > For starters, can you tell what triggered the assertion violation in > Juanma's case? IOW, how did we wind up in a situation where (AFAIU) > the selected window displays a buffer other than the current one? IIUC, here is the sequence: Function set_window_buffer (W, B, ...) is called where W is selected_window and XBUFFER (B) != current_buffer. This function temporary sets current buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, and these gets _finally_ synchronized only when read_key_sequence is called with fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], its routines may see the condition which was eassert'ed; _finally_ means that some redisplay routines may do the synchronization temporary and then restore original value of current buffer (see pos_visible_p for example). Dmitry From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 12:41:12 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 17:41:12 +0000 Received: from localhost ([127.0.0.1]:45463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te86q-0005aZ-Eo for submit@debbugs.gnu.org; Thu, 29 Nov 2012 12:41:12 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:58510) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te86n-0005aO-IF for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 12:41:10 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0ME900E00FJDLY00@a-mtaout21.012.net.il> for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 19:39:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME900E3JFP4HU40@a-mtaout21.012.net.il>; Thu, 29 Nov 2012 19:39:05 +0200 (IST) Date: Thu, 29 Nov 2012 19:39:25 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83r4ncux4i.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 09:02:13 -0800 > > > And Drew, could you please try coming up with a simple recipe starting > > with "emacs -Q"? If you define a configuration with a minibuffer-less > > frame, a separate minibuffer frame, and arrange for *Completions* to > > pop up yet another frame, then trigger completion in some simple way, > > does Emacs abort like in your original report? > > No, I'm sorry Eli, I just don't have the time for that now. I have reverted to > using the Emacs binary before these crashes were introduced. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 09:02:13 -0800 > > > And Drew, could you please try coming up with a simple recipe starting > > with "emacs -Q"? If you define a configuration with a minibuffer-less > > frame, a separate minibuffer frame, and arrange for *Completions* to > > pop up yet another frame, then trigger completion in some simple way, > > does Emacs abort like in your original report? > > No, I'm sorry Eli, I just don't have the time for that now. I have reverted to > using the Emacs binary before these crashes were introduced. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4434] > From: "Drew Adams" > Cc: <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 09:02:13 -0800 > > > And Drew, could you please try coming up with a simple recipe starting > > with "emacs -Q"? If you define a configuration with a minibuffer-less > > frame, a separate minibuffer frame, and arrange for *Completions* to > > pop up yet another frame, then trigger completion in some simple way, > > does Emacs abort like in your original report? > > No, I'm sorry Eli, I just don't have the time for that now. I have reverted to > using the Emacs binary before these crashes were introduced. Don't you still have the buggy binary on your disk somewhere? > If you happen to make some progress then I will be glad to try the result and > let you know the effect in my context. We cannot make progress, because we cannot reproduce your way to trigger the bug. > My guess (& hope) is that there is a good chance that Juanma and I were bitten > by the same bug. It's the same bug, in the sense that the same assertion is violated. But they are 2 different ways of triggering that violation, because the call to the faulty function comes from 2 different places (as evidenced by the backtrace) and the buffer that is not the current one is different in these two cases (*scratch* for Juanma, minibuffer for you). > If not, we can look into my case more later, when I have some more > time. Please do, and thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 12:49:28 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 17:49:28 +0000 Received: from localhost ([127.0.0.1]:45469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8Eq-0005mL-B4 for submit@debbugs.gnu.org; Thu, 29 Nov 2012 12:49:28 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:27163) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8Eo-0005mE-IS for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 12:49:27 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATHlN0e027376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 17:47:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qATHlMeD021510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 17:47:23 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qATHlMwQ007658; Thu, 29 Nov 2012 11:47:22 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Nov 2012 09:47:22 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> <83r4ncux4i.fsf@gnu.org> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Thu, 29 Nov 2012 09:47:21 -0800 Message-ID: <21A6DF1FEE8B411C86C172191120B2BE@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <83r4ncux4i.fsf@gnu.org> Thread-Index: Ac3OWHDjT1HTEBWyRemlOKyX88KR+wAABPNw X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > No, I'm sorry Eli, I just don't have the time for that now. > > I have reverted to using the Emacs binary before these > > crashes were introduced. > > Don't you still have the buggy binary on your disk somewhere? Yes, I do. > > If you happen to make some progress then I will be glad to > > try the result and let you know the effect in my context. > > We cannot make progress, because we cannot reproduce your way to > trigger the bug. Then we'll just have to wait until you obtain a recipe from someone else for a different way to trigger "the bug" or perhaps a related bug. > > My guess (& hope) is that there is a good chance that > > Juanma and I were bitten by the same bug. > > It's the same bug, in the sense that the same assertion is violated. > But they are 2 different ways of triggering that violation, because > the call to the faulty function comes from 2 different places (as > evidenced by the backtrace) and the buffer that is not the current one > is different in these two cases (*scratch* for Juanma, minibuffer for > you). Don't you think that by understanding Juanma's case you will understand ways, in general, that the assertion can be violated? If we have already seen more than one way, as you say, that seems like a good hint that the assertion itself might be flawed: the wrong assertion. It suggests to me that the assertion does not understand what it should be expecting, and it has too narrow a view of things. IOW, I would expect Juanma's case to turn on some light wrt how the assertion is wrong. That's because I'm guessing that the code (apparently more than one code path) that violates the assertion is not the problem, and the assertion itself is the problem: the wrong assertion. (Just a hunch, from ignorance.) > > If not, we can look into my case more later, when I have some more > > time. > > Please do, and thanks. Thank you for trying to find a solution. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 13:10:49 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 18:10:49 +0000 Received: from localhost ([127.0.0.1]:45498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8ZV-0007A6-7H for submit@debbugs.gnu.org; Thu, 29 Nov 2012 13:10:49 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:39515) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8ZT-00079z-44 for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 13:10:47 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ME900800GZHWY00@a-mtaout22.012.net.il> for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 20:08:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME9008ZCH2EAPF0@a-mtaout22.012.net.il>; Thu, 29 Nov 2012 20:08:38 +0200 (IST) Date: Thu, 29 Nov 2012 20:08:59 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <21A6DF1FEE8B411C86C172191120B2BE@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83obiguvr8.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> <83r4ncux4i.fsf@gnu.org> <21A6DF1FEE8B411C86C172191120B2BE@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 09:47:21 -0800 > > > It's the same bug, in the sense that the same assertion is violated. > > But they are 2 different ways of triggering that violation, because > > the call to the faulty function comes from 2 different places (as > > evidenced by the backtrace) and the buffer that is not the current one > > is different in these two cases (*scratch* for Juanma, minibuffer for > > you). > > Don't you think that by understanding Juanma's case you will understand ways, in > general, that the assertion can be violated? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4996] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: "Drew Adams" > Cc: , <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 09:47:21 -0800 > > > It's the same bug, in the sense that the same assertion is violated. > > But they are 2 different ways of triggering that violation, because > > the call to the faulty function comes from 2 different places (as > > evidenced by the backtrace) and the buffer that is not the current one > > is different in these two cases (*scratch* for Juanma, minibuffer for > > you). > > Don't you think that by understanding Juanma's case you will understand ways, in > general, that the assertion can be violated? There is no "general" here, just a lot of different use-cases. > If we have already seen more than one way, as you say, that seems like a good > hint that the assertion itself might be flawed: the wrong assertion. It > suggests to me that the assertion does not understand what it should be > expecting, and it has too narrow a view of things. Yes, that part is clear, and therefore the assertion was removed from the trunk. But we are trying to figure out with what to replace it, and for that, we need as many use-cases that violate it as possible. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 13:15:44 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 18:15:44 +0000 Received: from localhost ([127.0.0.1]:45503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8eD-0007H2-UX for submit@debbugs.gnu.org; Thu, 29 Nov 2012 13:15:43 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:30986) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8eA-0007Gu-AE for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 13:15:39 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATIDZdq025050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 18:13:36 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qATIDZDc006249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 18:13:35 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qATIDZjE028238; Thu, 29 Nov 2012 12:13:35 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Nov 2012 10:13:34 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> <83r4ncux4i.fsf@gnu.org> <21A6DF1FEE8B411C86C172191120B2BE@us.oracle.com> <83obiguvr8.fsf@gnu.org> Subject: RE: bug#13007: 24.3.50; emacs_backtrace.txt Date: Thu, 29 Nov 2012 10:13:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <83obiguvr8.fsf@gnu.org> Thread-Index: Ac3OXJSohIU12ejHSNOWQ6IxUidUKQAAGBFA X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > If we have already seen more than one way, as you say, that > > seems like a good hint that the assertion itself might be > > flawed: the wrong assertion. It suggests to me that the > > assertion does not understand what it should be > > expecting, and it has too narrow a view of things. > > Yes, that part is clear, and therefore the assertion was removed from > the trunk. But we are trying to figure out with what to replace it, > and for that, we need as many use-cases that violate it as possible. In that case, you are in effect stating that the addition of such a (proper) assertion is just a nice-to-have, not something needed. I would suggest, in that case, that we/you move on to other things... From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 14:16:18 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 19:16:18 +0000 Received: from localhost ([127.0.0.1]:45551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te9as-0000Iu-I5 for submit@debbugs.gnu.org; Thu, 29 Nov 2012 14:16:18 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:55892) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te9ap-0000Im-Na for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 14:16:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09FxKh9/2dsb2JhbABEsEiDSYEIghYBBVYjEAs0EhQYDSSIIboJkEQDiEKVd4R6gViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="208765619" Received: from 69-196-168-125.dsl.teksavvy.com (HELO ceviche.home) ([69.196.168.125]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 29 Nov 2012 14:14:14 -0500 Received: by ceviche.home (Postfix, from userid 20848) id D470D66127; Thu, 29 Nov 2012 14:14:13 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt Message-ID: References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> Date: Thu, 29 Nov 2012 14:14:13 -0500 In-Reply-To: <83txs8uzkc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Nov 2012 18:46:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, Dmitry Antipov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) FWIW, it's normal for current-buffer to be different from (window-buffer (selected-window)). That happens all the time in Elisp (e.g. whenever you use `set-buffer'). So if a piece of code needs the two to be "in sync" that code needs to sync-them-up by hand. Otherwise, it's better not to assume that the two are related. This is quite different from the issue of (selected-window) -vs- (frame-selected-window) where this is (almost) always equal and that equality can't be broken by Elisp code. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 14:51:58 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 19:51:58 +0000 Received: from localhost ([127.0.0.1]:45580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeA9N-0001BB-Qu for submit@debbugs.gnu.org; Thu, 29 Nov 2012 14:51:58 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:46228) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeA9K-0001Ax-6r for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 14:51:55 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0ME900E00LN0RN00@a-mtaout23.012.net.il> for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 21:49:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME900ETKLR1N640@a-mtaout23.012.net.il>; Thu, 29 Nov 2012 21:49:50 +0200 (IST) Date: Thu, 29 Nov 2012 21:50:11 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83lidkur2k.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <1865DC8EC71E4B78B074A727C299C875@us.oracle.com> <83r4ncux4i.fsf@gnu.org> <21A6DF1FEE8B411C86C172191120B2BE@us.oracle.com> <83obiguvr8.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 10:13:33 -0800 > > > > If we have already seen more than one way, as you say, that > > > seems like a good hint that the assertion itself might be > > > flawed: the wrong assertion. It suggests to me that the > > > assertion does not understand what it should be > > > expecting, and it has too narrow a view of things. > > > > Yes, that part is clear, and therefore the assertion was removed from > > the trunk. But we are trying to figure out with what to replace it, > > and for that, we need as many use-cases that violate it as possible. > > In that case, you are in effect stating that the addition of such a (proper) > assertion is just a nice-to-have, not something needed. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4997] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: "Drew Adams" > Cc: , <13007@debbugs.gnu.org>, > Date: Thu, 29 Nov 2012 10:13:33 -0800 > > > > If we have already seen more than one way, as you say, that > > > seems like a good hint that the assertion itself might be > > > flawed: the wrong assertion. It suggests to me that the > > > assertion does not understand what it should be > > > expecting, and it has too narrow a view of things. > > > > Yes, that part is clear, and therefore the assertion was removed from > > the trunk. But we are trying to figure out with what to replace it, > > and for that, we need as many use-cases that violate it as possible. > > In that case, you are in effect stating that the addition of such a (proper) > assertion is just a nice-to-have, not something needed. Assertions are always "nice to have". They are a means of catching bugs that violate assumptions of the code before that code causes harm or crashes in a place where the original reason is lost. If you think this is not needed, then we will have to disagree. There are hundreds of assertions in the Emacs code (grep for "eassert"). > I would suggest, in that case, that we/you move on to other things... I'm sorry to hear that you won't help. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 29 14:56:05 2012 Received: (at 13007) by debbugs.gnu.org; 29 Nov 2012 19:56:05 +0000 Received: from localhost ([127.0.0.1]:45584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeADN-0001HI-HN for submit@debbugs.gnu.org; Thu, 29 Nov 2012 14:56:05 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:32918) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeADL-0001HA-4h for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 14:56:03 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ME900900LSEY100@a-mtaout22.012.net.il> for 13007@debbugs.gnu.org; Thu, 29 Nov 2012 21:54:00 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME9009SILY0SU30@a-mtaout22.012.net.il>; Thu, 29 Nov 2012 21:54:00 +0200 (IST) Date: Thu, 29 Nov 2012 21:54:21 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83k3t4uqvm.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Dmitry Antipov , 13007@debbugs.gnu.org, lekktu@gmail.com > Date: Thu, 29 Nov 2012 14:14:13 -0500 > > FWIW, it's normal for current-buffer to be different from (window-buffer > (selected-window)). That happens all the time in Elisp (e.g. whenever > you use `set-buffer'). We are talking about redisplay, not Lisp. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 30 04:55:35 2012 Received: (at 13007) by debbugs.gnu.org; 30 Nov 2012 09:55:35 +0000 Received: from localhost ([127.0.0.1]:46215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeNJn-0006cO-9k for submit@debbugs.gnu.org; Fri, 30 Nov 2012 04:55:35 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:38668) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeNJk-0006cG-TR for 13007@debbugs.gnu.org; Fri, 30 Nov 2012 04:55:33 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MEA00H00OOZ9900@a-mtaout22.012.net.il> for 13007@debbugs.gnu.org; Fri, 30 Nov 2012 11:53:26 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEA00HG4OT22760@a-mtaout22.012.net.il>; Fri, 30 Nov 2012 11:53:26 +0200 (IST) Date: Fri, 30 Nov 2012 11:53:11 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <50B79A19.2050707@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83a9tzv2m0.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 29 Nov 2012 21:23:37 +0400 > From: Dmitry Antipov > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/29/2012 08:46 PM, Eli Zaretskii wrote: > > > For starters, can you tell what triggered the assertion violation in > > Juanma's case? IOW, how did we wind up in a situation where (AFAIU) > > the selected window displays a buffer other than the current one? > > IIUC, here is the sequence: > > Function set_window_buffer (W, B, ...) is called where W is selected_window > and XBUFFER (B) != current_buffer. This function temporary sets current > buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. > So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, > and these gets _finally_ synchronized only when read_key_sequence is called with > fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], > its routines may see the condition which was eassert'ed; _finally_ means > that some redisplay routines may do the synchronization temporary and > then restore original value of current buffer (see pos_visible_p for example). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4956] X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Thu, 29 Nov 2012 21:23:37 +0400 > From: Dmitry Antipov > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/29/2012 08:46 PM, Eli Zaretskii wrote: > > > For starters, can you tell what triggered the assertion violation in > > Juanma's case? IOW, how did we wind up in a situation where (AFAIU) > > the selected window displays a buffer other than the current one? > > IIUC, here is the sequence: > > Function set_window_buffer (W, B, ...) is called where W is selected_window > and XBUFFER (B) != current_buffer. This function temporary sets current > buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. > So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, > and these gets _finally_ synchronized only when read_key_sequence is called with > fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], > its routines may see the condition which was eassert'ed; _finally_ means > that some redisplay routines may do the synchronization temporary and > then restore original value of current buffer (see pos_visible_p for example). OK. So what do you suggest, in practical terms? Are you saying that we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF inside window_outdated? Or do you suggest something else? I'm okay with using BUF_* macros in window_outdated. My reading of redisplay_internal is that it goes by the selected window, not assuming that the buffer of that window is the current buffer. But when redisplay_window is called, it temporarily selects the window's buffer as current buffer, and all the functions called by redisplay_window then rely on that. So if window_outdated is called not from redisplay_window or its subroutines, we cannot assume that current_buffer and the selected window's buffer are the same. Also, for minibuffer windows and pseudo-windows, we may need more care, but I'm not sure. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 30 10:53:11 2012 Received: (at 13007) by debbugs.gnu.org; 30 Nov 2012 15:53:11 +0000 Received: from localhost ([127.0.0.1]:47188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeStr-0007Yx-ED for submit@debbugs.gnu.org; Fri, 30 Nov 2012 10:53:11 -0500 Received: from forward3h.mail.yandex.net ([84.201.187.148]:47405) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeStn-0007Ym-71 for 13007@debbugs.gnu.org; Fri, 30 Nov 2012 10:53:10 -0500 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 915A41361FEB; Fri, 30 Nov 2012 19:50:58 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 228EA17002C0; Fri, 30 Nov 2012 19:50:58 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oun4L1YL-ovnOrO55; Fri, 30 Nov 2012 19:50:57 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1354290658; bh=HlzOnFds5u7ADL+0aLL3dfIKOm95hrADRSw3daKfnV4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=Vk3q0aWPuQoaSK3HDsJNHGyqlfc5Z3PxgezF3FGC//smOGwdT0FS1dlQQU6UkZEHJ rrXlmhUhEhqOE8xdtCIodX4KN7Rd3x3xoH1rRtnVXdOOQluFwqncAfGTRYUZnsjnPc Q3GTi8UVKKYOl6dAJY4uWykst+HItpJi1CklFQHw= Message-ID: <50B8D5E1.7090005@yandex.ru> Date: Fri, 30 Nov 2012 19:50:57 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> <83a9tzv2m0.fsf@gnu.org> In-Reply-To: <83a9tzv2m0.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------090600030603000200040403" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) This is a multi-part message in MIME format. --------------090600030603000200040403 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/30/2012 01:53 PM, Eli Zaretskii wrote: > OK. So what do you suggest, in practical terms? Are you saying that > we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and > BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF > inside window_outdated? Or do you suggest something else? > > I'm okay with using BUF_* macros in window_outdated. There is one more similar thing: if we can enter redisplay_internal with different current_buffer and selected window's buffer, we can confuse reconsider_clip_changes, which comment explicitly assumes that W->buffer and B are the same buffer. What if we just delay the real redisplay action until current_buffer and selected window's buffer becomes synchronized, assuming that it happens in the very near future (when someone finally update current_buffer with selected window's buffer and then attract redisplay attention with ++windows_or_buffers_changed or similar)? > So if window_outdated is called not from redisplay_window or its > subroutines, we cannot assume that current_buffer and the selected > window's buffer are the same. Also, for minibuffer windows and > pseudo-windows, we may need more care, but I'm not sure. IIUC pseudo-windows are always non-leaf; so, selected_window can't be a pseudo-window, and pseudo-window can't be passed to redisplay_window. Attached patch illustrates all from the above. Dmitry --------------090600030603000200040403 Content-Type: text/plain; charset=UTF-8; name="3.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="3.patch" PT09IG1vZGlmaWVkIGZpbGUgJ3NyYy94ZGlzcC5jJwotLS0gc3JjL3hkaXNwLmMJMjAxMi0x MS0zMCAwOToyMzoxNSArMDAwMAorKysgc3JjL3hkaXNwLmMJMjAxMi0xMS0zMCAxNTo0NToz NiArMDAwMApAQCAtMTA5MDYsNiArMTA5MDYsNyBAQAogc3RhdGljIGludAogd2luZG93X291 dGRhdGVkIChzdHJ1Y3Qgd2luZG93ICp3KQogeworICBlYXNzZXJ0IChYQlVGRkVSICh3LT5i dWZmZXIpID09IGN1cnJlbnRfYnVmZmVyKTsKICAgcmV0dXJuICh3LT5sYXN0X21vZGlmaWVk IDwgTU9ESUZGIAogCSAgfHwgdy0+bGFzdF9vdmVybGF5X21vZGlmaWVkIDwgT1ZFUkxBWV9N T0RJRkYpOwogfQpAQCAtMTI5MTcsNiArMTI5MTgsOCBAQAogc3RhdGljIHZvaWQKIHJlY29u c2lkZXJfY2xpcF9jaGFuZ2VzIChzdHJ1Y3Qgd2luZG93ICp3LCBzdHJ1Y3QgYnVmZmVyICpi KQogeworICBlYXNzZXJ0IChYQlVGRkVSICh3LT5idWZmZXIpID09IGIpOworCiAgIGlmIChi LT5jbGlwX2NoYW5nZWQKIAkgICAmJiAhTklMUCAody0+d2luZG93X2VuZF92YWxpZCkKIAkg ICAmJiB3LT5jdXJyZW50X21hdHJpeC0+YnVmZmVyID09IGIKQEAgLTEyOTI0LDEzICsxMjky NywxMSBAQAogCSAgICYmIHctPmN1cnJlbnRfbWF0cml4LT5iZWd2ID09IEJVRl9CRUdWIChi KSkKICAgICBiLT5jbGlwX2NoYW5nZWQgPSAwOwogCi0gIC8qIElmIGRpc3BsYXkgd2Fzbid0 IHBhdXNlZCwgYW5kIFcgaXMgbm90IGEgdG9vbCBiYXIgd2luZG93LCBzZWUgaWYKLSAgICAg cG9pbnQgaGFzIGJlZW4gbW92ZWQgaW50byBvciBvdXQgb2YgYSBjb21wb3NpdGlvbi4gIElu IHRoYXQgY2FzZSwKLSAgICAgd2Ugc2V0IGItPmNsaXBfY2hhbmdlZCB0byAxIHRvIGZvcmNl IHVwZGF0aW5nIHRoZSBzY3JlZW4uICBJZgotICAgICBiLT5jbGlwX2NoYW5nZWQgaGFzIGFs cmVhZHkgYmVlbiBzZXQgdG8gMSwgd2UgY2FuIHNraXAgdGhpcwotICAgICBjaGVjay4gICov Ci0gIGlmICghYi0+Y2xpcF9jaGFuZ2VkCi0gICAgICAmJiBCVUZGRVJQICh3LT5idWZmZXIp ICYmICFOSUxQICh3LT53aW5kb3dfZW5kX3ZhbGlkKSkKKyAgLyogSWYgZGlzcGxheSB3YXNu J3QgcGF1c2VkLCBzZWUgaWYgcG9pbnQgaGFzIGJlZW4gbW92ZWQgaW50byBvcgorICAgICBv dXQgb2YgYSBjb21wb3NpdGlvbi4gIEluIHRoYXQgY2FzZSwgd2Ugc2V0IGItPmNsaXBfY2hh bmdlZAorICAgICB0byAxIHRvIGZvcmNlIHVwZGF0aW5nIHRoZSBzY3JlZW4uICBJZiBiLT5j bGlwX2NoYW5nZWQgaGFzCisgICAgIGFscmVhZHkgYmVlbiBzZXQgdG8gMSwgd2UgY2FuIHNr aXAgdGhpcyBjaGVjay4gICovCisgIGlmICghYi0+Y2xpcF9jaGFuZ2VkICYmICFOSUxQICh3 LT53aW5kb3dfZW5kX3ZhbGlkKSkKICAgICB7CiAgICAgICBwdHJkaWZmX3QgcHQ7CiAKQEAg LTEzMDc5LDYgKzEzMDgwLDEwIEBACiAgICAgIG1heSBuZWVkIHRvIHJ1biBFbGlzcCBjb2Rl ICh2aWEgcHJlcGFyZV9tZW51X2JhcnMpLiAgKi8KICAgZW5zdXJlX3NlbGVjdGVkX2ZyYW1l IChvbGRfZnJhbWUpOwogCisgIGlmIChYQlVGRkVSICh3LT5idWZmZXIpICE9IGN1cnJlbnRf YnVmZmVyKQorICAgIC8qIE91dCBvZiBzeW5jLCBkbyBub3RoaW5nLiAgKi8KKyAgICBnb3Rv IGVuZF9vZl9yZWRpc3BsYXk7CisKICAgcGVuZGluZyA9IDA7CiAgIHJlY29uc2lkZXJfY2xp cF9jaGFuZ2VzICh3LCBjdXJyZW50X2J1ZmZlcik7CiAgIGxhc3RfZXNjYXBlX2dseXBoX2Zy YW1lID0gTlVMTDsKQEAgLTEzMTM2LDEwICsxMzE0MSw3IEBACiAgIC8qIGRvX3BlbmRpbmdf d2luZG93X2NoYW5nZSBjb3VsZCBjaGFuZ2UgdGhlIHNlbGVjdGVkX3dpbmRvdyBkdWUgdG8K ICAgICAgZnJhbWUgcmVzaXppbmcgd2hpY2ggbWFrZXMgdGhlIHNlbGVjdGVkIHdpbmRvdyB0 b28gc21hbGwuICAqLwogICBpZiAoV0lORE9XUCAoc2VsZWN0ZWRfd2luZG93KSAmJiAodyA9 IFhXSU5ET1cgKHNlbGVjdGVkX3dpbmRvdykpICE9IHN3KQotICAgIHsKLSAgICAgIHN3ID0g dzsKLSAgICAgIHJlY29uc2lkZXJfY2xpcF9jaGFuZ2VzICh3LCBjdXJyZW50X2J1ZmZlcik7 Ci0gICAgfQorICAgIGdvdG8gcmV0cnk7CiAKICAgLyogQ2xlYXIgZnJhbWVzIG1hcmtlZCBh cyBnYXJiYWdlZC4gICovCiAgIGNsZWFyX2dhcmJhZ2VkX2ZyYW1lcyAoKTsKCg== --------------090600030603000200040403-- From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 30 12:02:13 2012 Received: (at 13007) by debbugs.gnu.org; 30 Nov 2012 17:02:13 +0000 Received: from localhost ([127.0.0.1]:47217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeTye-0000g1-Ei for submit@debbugs.gnu.org; Fri, 30 Nov 2012 12:02:12 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:56943) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeTyb-0000fn-EV for 13007@debbugs.gnu.org; Fri, 30 Nov 2012 12:02:10 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MEB00K0089H7R00@a-mtaout23.012.net.il> for 13007@debbugs.gnu.org; Fri, 30 Nov 2012 19:00:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEB00J128K0YQC0@a-mtaout23.012.net.il>; Fri, 30 Nov 2012 19:00:01 +0200 (IST) Date: Fri, 30 Nov 2012 18:59:47 +0200 From: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt In-reply-to: <50B8D5E1.7090005@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83txs7t4ak.fsf@gnu.org> References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> <83a9tzv2m0.fsf@gnu.org> <50B8D5E1.7090005@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Fri, 30 Nov 2012 19:50:57 +0400 > From: Dmitry Antipov > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > There is one more similar thing: if we can enter redisplay_internal > with different current_buffer and selected window's buffer, we can > confuse reconsider_clip_changes, which comment explicitly assumes > that W->buffer and B are the same buffer. I don't see that. That function checks if the buffer is the same as the one recorded in window's matrix. > What if we just delay the real redisplay action until current_buffer > and selected window's buffer becomes synchronized, assuming that it > happens in the very near future (when someone finally update current_buffer > with selected window's buffer and then attract redisplay attention with > ++windows_or_buffers_changed or similar)? I don't think you can do that, since sometimes a non-selected window needs to be redisplayed. > IIUC pseudo-windows are always non-leaf; so, selected_window can't be > a pseudo-window, and pseudo-window can't be passed to redisplay_window. Are the menu-bar and tool-bar "windows" non-leaf? > static void > reconsider_clip_changes (struct window *w, struct buffer *b) > { > + eassert (XBUFFER (w->buffer) == b); > + How is this different from this: > if (b->clip_changed > && !NILP (w->window_end_valid) > && w->current_matrix->buffer == b ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + if (XBUFFER (w->buffer) != current_buffer) > + /* Out of sync, do nothing. */ > + goto end_of_redisplay; I'm nervous about this, to tell the truth. redisplay_internal never dependent on current_buffer. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 06:09:17 2015 Received: (at 13007) by debbugs.gnu.org; 29 Dec 2015 11:09:17 +0000 Received: from localhost ([127.0.0.1]:47325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDs9V-0008FS-5A for submit@debbugs.gnu.org; Tue, 29 Dec 2015 06:09:17 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:50016) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDs9T-0008FJ-2o for 13007@debbugs.gnu.org; Tue, 29 Dec 2015 06:09:15 -0500 Received: from 2.150.58.24.tmi.telenormobil.no ([2.150.58.24] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aDs96-0002Hi-4D; Tue, 29 Dec 2015 12:08:52 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> <83a9tzv2m0.fsf@gnu.org> Date: Tue, 29 Dec 2015 12:08:49 +0100 In-Reply-To: <83a9tzv2m0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Nov 2012 11:53:11 +0200") Message-ID: <87si2lldfi.fsf@gnus.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1aDs96-0002Hi-4D X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1451992132.55672@8SRqQpJJ4N94JlAlIPl/TA X-Spam-Status: No X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, Dmitry Antipov , drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> Function set_window_buffer (W, B, ...) is called where W is selected_window >> and XBUFFER (B) != current_buffer. This function temporary sets current >> buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. >> So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, >> and these gets _finally_ synchronized only when read_key_sequence is called with >> fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], >> its routines may see the condition which was eassert'ed; _finally_ means >> that some redisplay routines may do the synchronization temporary and >> then restore original value of current buffer (see pos_visible_p for example). > > OK. So what do you suggest, in practical terms? Are you saying that > we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and > BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF > inside window_outdated? Or do you suggest something else? > > I'm okay with using BUF_* macros in window_outdated. It's unclear what the conclusion here was. Is there anything more to be done in this bug report? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 12:37:03 2015 Received: (at 13007) by debbugs.gnu.org; 29 Dec 2015 17:37:03 +0000 Received: from localhost ([127.0.0.1]:48846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDyCk-0001y2-DV for submit@debbugs.gnu.org; Tue, 29 Dec 2015 12:37:03 -0500 Received: from eggs.gnu.org ([208.118.235.92]:32931) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDyCf-0001xR-Ne for 13007@debbugs.gnu.org; Tue, 29 Dec 2015 12:37:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDyCX-0003Zh-JN for 13007@debbugs.gnu.org; Tue, 29 Dec 2015 12:36:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDyCN-0003Xx-Mh; Tue, 29 Dec 2015 12:36:39 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4571 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aDyCM-0006Pc-TT; Tue, 29 Dec 2015 12:36:39 -0500 Date: Tue, 29 Dec 2015 19:37:32 +0200 Message-Id: <83a8otdulf.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87si2lldfi.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 29 Dec 2015 12:08:49 +0100) Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> <83a9tzv2m0.fsf@gnu.org> <87si2lldfi.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13007 Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Lars Ingebrigtsen > Cc: Dmitry Antipov , 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > Date: Tue, 29 Dec 2015 12:08:49 +0100 > > It's unclear what the conclusion here was. Is there anything more to be > done in this bug report? Let me take another look at this. Soon, I hope. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 02 06:10:49 2016 Received: (at 13007-done) by debbugs.gnu.org; 2 Jan 2016 11:10:49 +0000 Received: from localhost ([127.0.0.1]:34291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFK57-00015j-Qx for submit@debbugs.gnu.org; Sat, 02 Jan 2016 06:10:49 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52024) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFK53-00015R-AY for 13007-done@debbugs.gnu.org; Sat, 02 Jan 2016 06:10:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFK4u-0002jB-5j for 13007-done@debbugs.gnu.org; Sat, 02 Jan 2016 06:10:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFK4j-0002ff-75; Sat, 02 Jan 2016 06:10:21 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1506 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aFK4i-0002Il-FR; Sat, 02 Jan 2016 06:10:20 -0500 Date: Sat, 02 Jan 2016 13:10:17 +0200 Message-Id: <83si2gb5k6.fsf@gnu.org> From: Eli Zaretskii To: larsi@gnus.org In-reply-to: <83a8otdulf.fsf@gnu.org> (message from Eli Zaretskii on Tue, 29 Dec 2015 19:37:32 +0200) Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt References: <9FE4F131C0C94FC79470495A8506A387@us.oracle.com> <83k3t7xemd.fsf@gnu.org> <50B4EF28.6040905@yandex.ru> <834nkbx7if.fsf@gnu.org> <50B5BB01.2070304@yandex.ru> <50B63309.1070404@yandex.ru> <838v9lwqvn.fsf@gnu.org> <50B6FE89.20304@yandex.ru> <83txs8uzkc.fsf@gnu.org> <50B79A19.2050707@yandex.ru> <83a9tzv2m0.fsf@gnu.org> <87si2lldfi.fsf@gnus.org> <83a8otdulf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13007-done Cc: 13007-done@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Tue, 29 Dec 2015 19:37:32 +0200 > From: Eli Zaretskii > Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru > > > From: Lars Ingebrigtsen > > Cc: Dmitry Antipov , 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > Date: Tue, 29 Dec 2015 12:08:49 +0100 > > > > It's unclear what the conclusion here was. Is there anything more to be > > done in this bug report? > > Let me take another look at this. Soon, I hope. I see that Dmitry did modify window_outdated back in Aug 2013 (commit 170da1e) to use the BUF_MODIFF and BUF_OVERLAY_MODIFF macros that accept a buffer as their arguments, and removed the offending assertion. So this bug was actually resolved back then, and I'm now marking it as done. Thanks. From unknown Fri Aug 15 04:03:04 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 30 Jan 2016 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator