From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#30800: 26.0.91; unknown crash on macos Date: Wed, 21 Mar 2018 19:19:03 +0000 Message-ID: <20180321191903.GA38993@breton.holly.idiocy.org> References: <83muz1jrdv.fsf@gnu.org> <83k1u5jqxm.fsf@gnu.org> <83in9pjnkc.fsf@gnu.org> <83fu4tjmdv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1521659894 6255 195.159.176.226 (21 Mar 2018 19:18:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2018 19:18:14 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) Cc: 30800@debbugs.gnu.org, Aaron Jensen To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 21 20:18:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1eyjFR-0001Wn-JO for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Mar 2018 20:18:09 +0100 Original-Received: from localhost ([::1]:56927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyjHU-0002DG-Oe for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Mar 2018 15:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyjHL-00027T-B1 for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2018 15:20:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyjHG-0003w5-GS for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2018 15:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38349) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eyjHG-0003vn-C3 for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2018 15:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eyjHF-0007gh-Op for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2018 15:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Mar 2018 19:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30800 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30800-submit@debbugs.gnu.org id=B30800.152165995529494 (code B ref 30800); Wed, 21 Mar 2018 19:20:01 +0000 Original-Received: (at 30800) by debbugs.gnu.org; 21 Mar 2018 19:19:15 +0000 Original-Received: from localhost ([127.0.0.1]:46246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjGU-0007fe-Qe for submit@debbugs.gnu.org; Wed, 21 Mar 2018 15:19:14 -0400 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:39237) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjGT-0007fR-7T for 30800@debbugs.gnu.org; Wed, 21 Mar 2018 15:19:13 -0400 Original-Received: by mail-wm0-f46.google.com with SMTP id f125so11830471wme.4 for <30800@debbugs.gnu.org>; Wed, 21 Mar 2018 12:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=FcCzK2fKnxuUngFnVlNgWmbUclHtbeV7rbCbBVh6Q9c=; b=eiwc0RwYB9Fhm2JLGw6aSGwfsFwuRrrqxyE3npVgV/YX2iv7eOHXbIvSs2vPPUQ3Bs BO1W3ls8Mnm/JgmEXhgvRjdmu5lqlle1yFMhN8CiOHulxUJwFzc6rUpq1EpXQdNdoarS 9pMWZPbRmUSksKt+6Wu7Fq7mjkDWoVuyPx8gwp4XAJ79yFPCh7c+XAm8Ec+VEGeciyxj XdXVPKxV9jRSzr3QfCQAEW/koxDI5bwS8wClpMCJCifumO6sgH1fnTUA6lgCxmRtt3Di SX79f4Vtn8gkmYWd0ecRf7a0/D5B4qDtKPjibRV6kUhaWRrU08Z9a6hAbVQzWaPe0qvd wkKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=FcCzK2fKnxuUngFnVlNgWmbUclHtbeV7rbCbBVh6Q9c=; b=hmsKQ3P/tYyGEsmRUeYz+fXS2UxGokcbbUwxOmbN2m8JGZH2J/wddV0yo4vTv2povj lMuwgYHmwyG2ZQeZ0ECBrPkcUfQBaPe9enXj0fDfmlIccH7BarN5DmZUav0mEqucl+Eu AxtV+CU3S/r+VTpwOxc1xMmlbTOQVNLZI0K4ZKtASXIyLjVwQiuxMsRd4Ads/rzJxw7W 9GFQLTOQIzu+Cylg/ClahwRw8+DJliuY8PoAeP1eBwQunPQahbA9/3FGVzsaXcrrZxto XcYbxpXjQ6TWvA6gVB+Y7MR68Ydum/WAhBNr/cut/Sc4oaIVYeLroR9KR7/dSg1bCm4z 0faA== X-Gm-Message-State: AElRT7FITO4DXyB5YJe0RTEjckxvO7IZ77xewSHT2/kg2QXcXj3AhxcJ 9PUX7OY9hkFt8SjIbkWsb68= X-Google-Smtp-Source: AG47ELuai/x36wE/GQLT/IUV+yWZApBOb+tuGChm1cylyPTFEB0qNClN3OIscba2SEfelyFITOTTjQ== X-Received: by 10.28.164.3 with SMTP id n3mr3732802wme.121.1521659947179; Wed, 21 Mar 2018 12:19:07 -0700 (PDT) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-cd1d-06a5-d3d0-09f1.holly.idiocy.org. [2001:8b0:3f8:8129:cd1d:6a5:d3d0:9f1]) by smtp.gmail.com with ESMTPSA id f84sm5736335wmh.44.2018.03.21.12.19.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 12:19:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <83fu4tjmdv.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144503 Archived-At: On Wed, Mar 21, 2018 at 08:48:12PM +0200, Eli Zaretskii wrote: > It sounds like represented_frame might not get updated when the frame > whose pointer it holds is deleted. Maybe x_destroy_window should make > sure represented_frame is not the frame being deleted? > > Or maybe NS should not update represented_frame for child frames? The commit that introduced represented_frame was fixing some flickering. What it seems to have done is move the updating of the represented filename from being set synchronously to asynchronously. The represented filename tells the WM which file is being edited so it can show a matching icon in the titlebar and maybe some other stuff. It seems quite possible to me that the frame could be deleted in the interim. Could we check that the frame is still live in sendEvent? if (represented_filename != nil && FRAME_LIVE_P (represented_frame)) or just add if (represented_frame == f) represented_frame = NULL; to x_destroy_frame as you say. (I can’t help thinking it should be possible to update several frames in quick succession but only have the last actually updated since represented_filename and represented_frame are simply over‐written.) -- Alan Third