From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Test whether buffer/window is ready for start_display, etc. Date: Wed, 04 Oct 2017 19:35:13 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1507171604 23321 195.159.176.226 (5 Oct 2017 02:46:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Oct 2017 02:46:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 05 04:46:40 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzwBK-0004iR-01 for ged-emacs-devel@m.gmane.org; Thu, 05 Oct 2017 04:46:38 +0200 Original-Received: from localhost ([::1]:37558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzwBM-0007CY-KW for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 22:46:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzwAi-0007CG-VV for emacs-devel@gnu.org; Wed, 04 Oct 2017 22:46:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzwAe-00055j-2m for emacs-devel@gnu.org; Wed, 04 Oct 2017 22:46:01 -0400 Original-Received: from gateway33.websitewelcome.com ([192.185.145.216]:33715) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dzwAd-00054u-Tw for emacs-devel@gnu.org; Wed, 04 Oct 2017 22:45:56 -0400 Original-Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 89C9B138EF for ; Wed, 4 Oct 2017 21:35:14 -0500 (CDT) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id zvzTd3s8ZeM05zvzTdQ3rH; Wed, 04 Oct 2017 21:34:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:Cc:To:From:Message-ID:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lEcGzB+s47ltYXkArGfr2rFjkNS7r5NeZXf8W3ye90k=; b=Lp7CgSULKXxt187XthRJxgJzt6 cQ9OsP8l4cQgyZOkS1DywsrYCqll+fJJFnLUVPYw2VyIDZOq9i6AXExUGTAmT49Poh4pfuP0XduTA SypiBBl81latUZdAln21qT9++RAH6qnacu00xkvMNoNvGDRUHERwOyWxaLeCuf1yL8JNmOOL1kv9i Kbuzhrh3PqHEGFO9y1hDG5OeZlZgmIWOmemXCmt5iGQLE/dISlwABGu7kmVCUwbeNAh5lGcAFQx1Y Eoj6MR1C+MTu3Lr8qBLDZ78O+McdGvuoB13NWHBBvd++nqTFqIMYJQQxA53GcN+eh898yvkJPAaF7 Ay66xwcg==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:55598 helo=server.private) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1dzw0H-0042vd-Sb; Wed, 04 Oct 2017 21:35:13 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Exim-ID: 1dzw0H-0042vd-Sb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.private) [45.48.239.195]:55598 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 192.185.145.216 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219098 Archived-At: Thank you, Eli, for looking into this particular thread. Crosshairs and multiple fake cursors are drawn/erased when the following functions are called, each depending upon the flavor of Emacs (NS, X11, W32). This approach is based upon the existing method in which the real cursor is drawn. * ns_update_window_end (nsterm.m) * x_update_window_end (w32term.c) * x_update_window_end (xterm.c) Normally, redisplay gets to the above-functions when a window needs updating. I want crosshairs and/or fake cursors to be drawn/erased even when there is no need to update the window for any other reason. I throw the boolean switches for crosshairs and/or fake cursors a few different ways: toggle window.h switches with a function called from Lisp (sometimes attached to an idle timer, sometimes not); or, a keyboard press. The crosshairs and/or fake cursors also erase/draw if they were previously drawn on the window and the cache with their prior coordinates is still populated. When no window updating is required, redisplay_window is *not* called. The most common way for this to happen is an idle timer function being called. In order to make sure that *_update_window_end gets called when redisplay_window is *not* involved, I put in a condition preventing redisplay_internal from using "goto end_of_redisplay". In other words, if my boolean switches are "true", then do *not* "goto end_of_redisplay". When loading buffers with a custom desktop restore feature while Emacs is starting up, it is possible that this would normally be a "goto end_of_redisplay" condition that I have preempted. However, I would need to do more testing to see whether redisplay_window was called on the window where the crash occurred. The conditions of (w != XWINDOW (selected_window)) and (!WINDOW_VALID_P (selected_window)) were "wild guesses" on my part in an effort to help avoid potential future crashes. The conditions to see whether eassert would cause a crash in that situation (and immediately return if that would be the case) were implemented by me after three separate crashes and gdb told me said eassert conditions were the reasons: (CHARPOS (pos) >= BEGV && CHARPOS (pos) <= ZV); (charpos == BYTE_TO_CHAR (bytepos)); (BUF_BEG_BYTE (b) <= bytepos && bytepos <= BUF_Z_BYTE (b)) I have commented out the last check, which you indicated was redundant. I am happy to do more work on troubleshooting, which would entail removing the conditions that have prevented crashes and then get the backtraces -- perhaps that would tell me whether redisplay_window got bypassed such that preemption of "goto end_of_redisplay" is the problem.