[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Need help debugging Emacs: emacsclient will not draw its contents so
From: |
Mike Kupfer |
Subject: |
Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes |
Date: |
Wed, 17 Feb 2016 21:01:15 -0800 |
As suggested, I've opened a bug for this: #22728.
Eli Zaretskii wrote:
> > From: Mike Kupfer <address@hidden>
> > cc: address@hidden
> > Date: Tue, 16 Feb 2016 18:05:52 -0800
> >
> > I ran "emacsclient -c" twice within a short period of time, and the
> > server log showed 2 frames being created. So *some* code in Emacs
> > thought the first frame was created, even though it didn't show up
> > in the output from (frame-list).
>
> This means Emacs started creating the frame, but didn't finish that
> process. A new frame is recorded in the frame list only when it is
> completely set up. The question is: what happens during that process
> which prevents it from completing?
>
> 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.
I wonder if the problem is particular to a certain widget set. If
anyone has suggestions for instrumenting the Athena (2D) widget set, I'd
welcome them.
> > 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.
thanks and regards,
mike