Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Mike Kupfer <address@hidden>
> cc: address@hidden
> 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:
> 
>   (#<frame address@hidden 0x4eba368>
>    #<frame journal-2016.org 0x3073760>
>    #<frame *GNU Emacs* 0x1128268>)
> 
> (This was after the bad frame was created.)
> 
> The log showed the deletion of
> 
>   #<frame Todo.krb5-issues 0x4343058>
> 
> on the 12th, and the creation of
> 
>   #<frame address@hidden 0x4343058>
> 
> 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.