From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes Date: Sat, 20 Feb 2016 13:24:16 +0200 Message-ID: <838u2fpqu7.fsf@gnu.org> References: <1027.1455771675@allegro.localdomain> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455967497 22918 80.91.229.3 (20 Feb 2016 11:24:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Feb 2016 11:24:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mike Kupfer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 20 12:24:49 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aX5ea-0003Un-BC for ged-emacs-devel@m.gmane.org; Sat, 20 Feb 2016 12:24:48 +0100 Original-Received: from localhost ([::1]:60165 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX5eZ-0001MG-Mc for ged-emacs-devel@m.gmane.org; Sat, 20 Feb 2016 06:24:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX5eN-0001M8-Be for emacs-devel@gnu.org; Sat, 20 Feb 2016 06:24:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX5eK-0005VB-5N for emacs-devel@gnu.org; Sat, 20 Feb 2016 06:24:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX5eK-0005V7-27; Sat, 20 Feb 2016 06:24:32 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1425 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aX5eJ-0006XH-Ez; Sat, 20 Feb 2016 06:24:31 -0500 In-reply-to: <1027.1455771675@allegro.localdomain> (message from Mike Kupfer on Wed, 17 Feb 2016 21:01:15 -0800) 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200299 Archived-At: > From: Mike Kupfer > cc: emacs-devel@gnu.org > Date: Wed, 17 Feb 2016 21:01:15 -0800 > > > At this point, it looks like instrumenting x-create-frame to write > > traces to some file might tell what causes that function to stop doing > > its job half way through. > > Okay. If someone provides a patch, I'd be happy to apply it on the > systems I run Emacs on. I can also look at instrumenting > x-create-frame myself. That will take longer to set up, but given how > long it is between occurrences of this problem, some initial delay > probably doesn't matter much. Let me know if you need help in this matter. I can suggest some code, but I cannot easily test it. What I had in mind is adding code to x-create-frame, which would: . open a file with a certain fixed file name, in append mode . write series of trace info records to the file . close the file For the 2nd bullet above, inject 'fprintf' lines into x-create-frame at strategic places which record the frame name and address. The strategic places I'd consider are calls to other functions, especially those that are X and toolkit calls. Examples upon the first glance are: initialize_frame_menubar, x_wm_set_size_hint, adjust_frame_size, XChangeProperty, and the loop with calls fset_param_alist. The purpose of this is to find out which of these calls returns successfully, and which doesn't. Once we know which call doesn't return, we can look into that call to find out what happens there and why. > > > And I still think it's suspicious that the bad frame seems to match a > > > frame that was deleted earlier. > > > > Was the deleted frame deleted from the frame list? > > I'm not sure I understand the question. The frame list that I looked at > on the 15th had these 3 frames: > > (# > # > #) > > (This was after the bad frame was created.) > > The log showed the deletion of > > # > > on the 12th, and the creation of > > # > > on the 15th. Let me know if that doesn't answer your question. So you are saying that a new frame as created using the same address as used by a frame that was previously deleted. I don't think this means trouble, it just means Emacs reused the same memory for a new frame object.