bug#27816: 26.0.50; X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 2 Aug 2017 22:31:58 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Jean Louis <bugs@gnu.support>, 27816@debbugs.gnu.org
> 
> > > What I do, I read email by using mutt, then I hit r to reply email,
> > > including your emails, and I can see the notice from emacsclient on
> > > console, but the graphic frame is dropped, and later I see the bug in
> > > Emacs.
> 
> That is just one application on how I start
> emacsclient, but mutt is not related to it.
> 
> Another way of starting emacs is from terminal is
> as this:
> 
> emacsclient -s tmp/emacs1001/server -c
> Waiting for Emacs...
> 
> then each few times it works, like 85%, then it
> fails.
> 
> Emacs is running in background under screen, and
> it has (server-start) in .emacs or when I was
> testing without ~/.emacs I evaluated
> (server-start) in *scratch* buffer.
> 
> 28078 pts/0    Ssl+   2:02 /usr/bin/emacs --user admin --chdir /home/data1/protected
> 
> Then I run the emacsclient in following fashion:
> 
> 30859 pts/2    S+     0:00 emacsclient -c -s /home/data1/protected/tmp/emacs1001/server /home/data1/protected/tmp/mutt-protected-1001-30834-15325602171702686152
> 
> That means my main Emacs is running in console
> under screen, it is not just backgrounded
> daemon. But I do not think that it is related to
> screen.
> 
> I have noticed it now, that if one frame is open,
> the error is not appearing on the second frame.
> 
> It appears only when there is no existing frame,
> and new frame instance has to be open.
> 
> > guess is correct, it doesn't say whether
> > emacsclient is invoked to open a new frame or
> > reuse an old frame
> 
> The bug is appearing on opening a new instance of
> emacsclient frame when there is no other frame
> present.
> 
> > whether that frame is a GUI frame or a text-mode
> > frame
> 
> There is no problem with text mode frames. Just
> with GUI frame.
> 
> > and whether any other Emacs frames existed
> > before the invocation of emacsclient and were
> > supposed to remain after you finish editing the
> > response.
> 
> The text emacs is running under screen.
> 
> > Btw, does this happen only when emacsclient is
> > invoked from mutt, or also with other programs?
> 
> It happens if I invoke emacsclient by any means,
> when it is opening first frame.

Martin, could you please look into this?  It sounds like there's some
timing issue with drawing the scroll bars in this scenario, perhaps we
attempt to draw the scroll bar too early or something?

I wonder why no one else is seeing this problem, though.  This part:

> The problem is also happening when I do not run it under screen, I can
> run it as user.

seems to indicate that just doing the following should reproduce the
problem with ~25% probability, in an Emacs built with the Lucid
toolkit:

  $ emacs -Q -nw
  $ emacsclient -s tmp/emacs1001/server -c

Jean, does the above indeed reproduce the problem?

Btw, Jean, do you have any Emacs-related settings in your X resources?
(Although -Q should bypass those as well, AFAIR...)