GNU bug report logs -
#27816
26.0.50; X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
Previous Next
Reported by: bugs <at> gnu.support (Jean Louis)
Date: Tue, 25 Jul 2017 06:22:01 UTC
Severity: normal
Found in version 26.0.50
Fixed in version 26.1
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27816 in the body.
You can then email your comments to 27816 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Tue, 25 Jul 2017 06:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
bugs <at> gnu.support (Jean Louis):
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 25 Jul 2017 06:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I am using Emacs server, with emacsclient, and since last Git compile, I
am getting this error, and frames are being dropped or not appearing,
from time to time, not each time. It makes work hard.
X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
In GNU Emacs 26.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2017-07-24 built on protected.rcdrun.com
Repository revision: 6dc5d45c542a6f9cfbcf3e37d597c9e0efb3070d
Windowing system distributor 'The X.Org Foundation', version 11.0.11801000
System Description: GNU/Linux OS (GNU.Support) 0.1
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa
--with-modules --with-x --with-x-toolkit=lucid --without-gconf
--without-gsettings --without-libsystemd --without-dbus --without-pop
--with-mailutils --with-imagemagick
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/qt4/lib/pkgconfig:/opt/qt5/lib/pkgconfig'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote inotify dynamic-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 95171 7246)
(symbols 48 20362 1)
(miscs 40 43 108)
(strings 32 29315 1530)
(string-bytes 1 775225)
(vectors 16 13996)
(vector-slots 8 494125 10838)
(floats 8 50 66)
(intervals 56 247 5)
(buffers 992 12)
(heap 1024 41407 846))
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Tue, 25 Jul 2017 14:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> From: bugs <at> gnu.support (Jean Louis)
> Date: Tue, 25 Jul 2017 09:20:23 +0300
>
>
> I am using Emacs server, with emacsclient, and since last Git compile, I
> am getting this error, and frames are being dropped or not appearing,
> from time to time, not each time. It makes work hard.
When was your last Git compile before that?
> X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
The file etc/DEBUG describes how to start Emacs in the X synchronous
mode under a debugger (look for "X protocol errors"). Please invoke
Emacs as explained there, and then show the backtrace when the
breakpoint you set on the function x_error_quitter breaks. This will
tell us which code causes these errors, and hopefully provide enough
hints to identify the reason of this.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Tue, 25 Jul 2017 17:49:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 25, 2017 at 05:31:09PM +0300, Eli Zaretskii wrote:
> > From: bugs <at> gnu.support (Jean Louis)
> > Date: Tue, 25 Jul 2017 09:20:23 +0300
> >
> >
> > I am using Emacs server, with emacsclient, and since last Git compile, I
> > am getting this error, and frames are being dropped or not appearing,
> > from time to time, not each time. It makes work hard.
>
> When was your last Git compile before that?
>
> > X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
>
> The file etc/DEBUG describes how to start Emacs in the X synchronous
> mode under a debugger (look for "X protocol errors"). Please invoke
> Emacs as explained there, and then show the backtrace when the
> breakpoint you set on the function x_error_quitter breaks. This will
> tell us which code causes these errors, and hopefully provide enough
> hints to identify the reason of this.
>
> Thanks.
Thank you. As I must run Emacs as daemon, to run emacsclient, to
start debugging, when I run it as daemon with the
option (x-synchronize t) then I get this error:
error: X windows are not in use or not initialized
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.
Starting Emacs daemon.
(New file)
Or should I evaluate it later simply?
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Tue, 25 Jul 2017 18:34:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 25 Jul 2017 20:48:24 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
>
> > The file etc/DEBUG describes how to start Emacs in the X synchronous
> > mode under a debugger (look for "X protocol errors"). Please invoke
> > Emacs as explained there, and then show the backtrace when the
> > breakpoint you set on the function x_error_quitter breaks. This will
> > tell us which code causes these errors, and hopefully provide enough
> > hints to identify the reason of this.
> >
> > Thanks.
>
> Thank you. As I must run Emacs as daemon, to run emacsclient, to
> start debugging, when I run it as daemon with the
> option (x-synchronize t) then I get this error:
>
> error: X windows are not in use or not initialized
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file. Start Emacs with
> the ‘--debug-init’ option to view a complete error backtrace.
> Starting Emacs daemon.
> (New file)
>
> Or should I evaluate it later simply?
Yes, please evaluate it after you have created the first C frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 26 Jul 2017 05:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello,
When I get in gdb, when attaching to process:
ptrace: operation not permitted
do I then get requirements to debug?
On Tue, Jul 25, 2017 at 09:33:19PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 Jul 2017 20:48:24 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
> >
> > > The file etc/DEBUG describes how to start Emacs in the X synchronous
> > > mode under a debugger (look for "X protocol errors"). Please invoke
> > > Emacs as explained there, and then show the backtrace when the
> > > breakpoint you set on the function x_error_quitter breaks. This will
> > > tell us which code causes these errors, and hopefully provide enough
> > > hints to identify the reason of this.
> > >
> > > Thanks.
> >
> > Thank you. As I must run Emacs as daemon, to run emacsclient, to
> > start debugging, when I run it as daemon with the
> > option (x-synchronize t) then I get this error:
> >
> > error: X windows are not in use or not initialized
> >
> > To ensure normal operation, you should investigate and remove the
> > cause of the error in your initialization file. Start Emacs with
> > the ‘--debug-init’ option to view a complete error backtrace.
> > Starting Emacs daemon.
> > (New file)
> >
> > Or should I evaluate it later simply?
>
> Yes, please evaluate it after you have created the first C frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 26 Jul 2017 14:48:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 26 Jul 2017 08:25:45 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
>
> When I get in gdb, when attaching to process:
>
> ptrace: operation not permitted
>
> do I then get requirements to debug?
Ugh, sorry about your trouble. Does it work if you invoke GDB via
sudo?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 07:10:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 26, 2017 at 05:46:44PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 26 Jul 2017 08:25:45 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
> >
> > When I get in gdb, when attaching to process:
> >
> > ptrace: operation not permitted
> >
> > do I then get requirements to debug?
>
> Ugh, sorry about your trouble. Does it work if you invoke GDB via
> sudo?
I would really like to solve this problem, as it appears each few
times it does not work.
I am starting Emacs under user "admin" who reads emails, and answering
on many, from mutt mail client.
Emacs is started as daemon from a supervision script:
/usr/bin/emacs --user admin --chdir /home/data1/protected
I am now going to test it through GDB, and will let you know, but I
think it should work without sudo.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 07:39:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 25, 2017 at 09:33:19PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 Jul 2017 20:48:24 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
> >
> > > The file etc/DEBUG describes how to start Emacs in the X synchronous
> > > mode under a debugger (look for "X protocol errors"). Please invoke
> > > Emacs as explained there, and then show the backtrace when the
> > > breakpoint you set on the function x_error_quitter breaks. This will
> > > tell us which code causes these errors, and hopefully provide enough
> > > hints to identify the reason of this.
> > >
> > > Thanks.
> >
> > Thank you. As I must run Emacs as daemon, to run emacsclient, to
> > start debugging, when I run it as daemon with the
> > option (x-synchronize t) then I get this error:
> >
> > error: X windows are not in use or not initialized
> >
> > To ensure normal operation, you should investigate and remove the
> > cause of the error in your initialization file. Start Emacs with
> > the ‘--debug-init’ option to view a complete error backtrace.
> > Starting Emacs daemon.
> > (New file)
> >
> > Or should I evaluate it later simply?
>
> Yes, please evaluate it after you have created the first C frame.
I am starting Emacs through screen, without X windows. So I started as:
gdb screen
then I do:
breakpoint x_error_quitter
It asks me for future loaded libraries, I said y.
Then I "run" and get screen and bash.
Then I start emacs as
emacs --user admin --chdir /home/data1/protected (that is my home dir)
And then I connect to emacs as emacsclient
and evaluate (x-synchronize t)
and then if I connect each 4th or 5th time, not clearly known why,
then I get that bug, and X frame of new emacsclient is not appearing.
But back in debugger I do not see much, emacs as server is still
running. When I quit emacs, and screen, only then I can see backtrace
and it shows me nothing special related to emacs, just three lines.
Maybe you can help me, as I am doing something wrong, but I can replicate the bug.
If I just start emacs in X Window, and not in screen, in console,
under bash, without X Window, I do not get that bug, I tried repeating
it but I did not get it.
If I start it in console through screen, I get the bug.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 17:19:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 27 Jul 2017 10:38:27 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 27816 <at> debbugs.gnu.org
>
> I am starting Emacs through screen, without X windows. So I started as:
>
> gdb screen
>
> then I do:
>
> breakpoint x_error_quitter
>
> It asks me for future loaded libraries, I said y.
>
> Then I "run" and get screen and bash.
>
> Then I start emacs as
>
> emacs --user admin --chdir /home/data1/protected (that is my home dir)
No, I think this is a mistake. You should first start screen, then
start GDB from that like this:
gdb emacs
Then when GDB shows its prompt, type
(gdb) break x_error_quitter
(gdb) run --user admin --chdir /home/data1/protected
(The "(gdb)" part is the GDB prompt, you don't need to type it.)
And then continue as you usually would:
> And then I connect to emacs as emacsclient
>
> and evaluate (x-synchronize t)
>
> and then if I connect each 4th or 5th time, not clearly known why,
> then I get that bug, and X frame of new emacsclient is not appearing.
>
> But back in debugger I do not see much, emacs as server is still
> running.
If you start Emacs as above, you should see GDB take control when the
problem happens. Then type
(gdb) thread apply all bt
and post here everything it displays.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 19:27:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 27, 2017 at 08:18:00PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 27 Jul 2017 10:38:27 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 27816 <at> debbugs.gnu.org
> >
> > I am starting Emacs through screen, without X windows. So I started as:
> >
> > gdb screen
> >
> > then I do:
> >
> > breakpoint x_error_quitter
> >
> > It asks me for future loaded libraries, I said y.
> >
> > Then I "run" and get screen and bash.
> >
> > Then I start emacs as
> >
> > emacs --user admin --chdir /home/data1/protected (that is my home dir)
>
> No, I think this is a mistake. You should first start screen, then
> start GDB from that like this:
>
> gdb emacs
>
> Then when GDB shows its prompt, type
>
> (gdb) break x_error_quitter
> (gdb) run --user admin --chdir /home/data1/protected
When I start screen, it must be started in console, not under X, so when I do:
gdb emacs
and later
run --user admin --chdir /home/data1/protected
I loose the GDB prompt.
I will try setting it before run
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 19:31:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 27816 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Eli,
Thank you. I had to set first the breakpoint, as GDB prompt would not come back if I run emacs.
OK, here it is attached.
On Thu, Jul 27, 2017 at 08:18:00PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 27 Jul 2017 10:38:27 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 27816 <at> debbugs.gnu.org
> >
> > I am starting Emacs through screen, without X windows. So I started as:
> >
> > gdb screen
> >
> > then I do:
> >
> > breakpoint x_error_quitter
> >
> > It asks me for future loaded libraries, I said y.
> >
> > Then I "run" and get screen and bash.
> >
> > Then I start emacs as
> >
> > emacs --user admin --chdir /home/data1/protected (that is my home dir)
>
> No, I think this is a mistake. You should first start screen, then
> start GDB from that like this:
>
> gdb emacs
>
> Then when GDB shows its prompt, type
>
> (gdb) break x_error_quitter
> (gdb) run --user admin --chdir /home/data1/protected
>
> (The "(gdb)" part is the GDB prompt, you don't need to type it.)
> And then continue as you usually would:
>
> > And then I connect to emacs as emacsclient
> >
> > and evaluate (x-synchronize t)
> >
> > and then if I connect each 4th or 5th time, not clearly known why,
> > then I get that bug, and X frame of new emacsclient is not appearing.
> >
> > But back in debugger I do not see much, emacs as server is still
> > running.
>
> If you start Emacs as above, you should see GDB take control when the
> problem happens. Then type
>
> (gdb) thread apply all bt
>
> and post here everything it displays.
[screenlog.0 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 19:32:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 27 Jul 2017 22:25:37 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 27816 <at> debbugs.gnu.org
>
> When I start screen, it must be started in console, not under X, so when I do:
>
> gdb emacs
>
> and later
>
> run --user admin --chdir /home/data1/protected
>
> I loose the GDB prompt.
This is exactly what should happen. The GDB prompt will reappear when
the bug will happen.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 27 Jul 2017 20:32:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 27, 2017 at 10:31:09PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 27 Jul 2017 22:25:37 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 27816 <at> debbugs.gnu.org
> >
> > When I start screen, it must be started in console, not under X, so when I do:
> >
> > gdb emacs
> >
> > and later
> >
> > run --user admin --chdir /home/data1/protected
> >
> > I loose the GDB prompt.
>
> This is exactly what should happen. The GDB prompt will reappear when
> the bug will happen.
OK the GDB prompt appeared I guess on that
breakpoint, I hope you got the message.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 07:10:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 27 Jul 2017 22:30:29 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 27816 <at> debbugs.gnu.org
>
> Thank you. I had to set first the breakpoint, as GDB prompt would not come back if I run emacs.
>
> OK, here it is attached.
Thanks.
Earlier, asked when was your previous build, where this problem didn't
show. I don't think you answered that. Can you please provide that
information?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 08:29:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Do you know any way to find out history of when user did git pull? Than I could find it easily and I will try to find it out anyway. Maybe I could recompile few previous versions like taking half time period since I know it worked and then half of the half. I will find and let you know.
On July 28, 2017 10:09:03 AM GMT+03:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Thu, 27 Jul 2017 22:30:29 +0300
>> From: Jean Louis <bugs <at> gnu.support>
>> Cc: 27816 <at> debbugs.gnu.org
>>
>> Thank you. I had to set first the breakpoint, as GDB prompt would not
>come back if I run emacs.
>>
>> OK, here it is attached.
>
>Thanks.
>
>Earlier, asked when was your previous build, where this problem didn't
>show. I don't think you answered that. Can you please provide that
>information?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 08:44:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 28 Jul 2017 08:28:10 +0000
> CC: 27816 <at> debbugs.gnu.org
> From: Jean Louis <bugs <at> gnu.support>
>
> Do you know any way to find out history of when user did git pull?
Yes, "git reflog".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 08:48:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 28 Jul 2017 08:28:10 +0000
> CC: 27816 <at> debbugs.gnu.org
> From: Jean Louis <bugs <at> gnu.support>
>
> Do you know any way to find out history of when user did git pull?
Yes, "git reflog".
Also, if you still have the previous build's binary, you could start
it and then type
M-x emacs-version RET
M-: emacs-repository-version RET
The latter will show the Git SHA1 signature of the last commit on
master at the time you synced with upstream master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 21:32:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 28, 2017 at 10:09:03AM +0300, Eli Zaretskii wrote:
> > Date: Thu, 27 Jul 2017 22:30:29 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 27816 <at> debbugs.gnu.org
> >
> > Thank you. I had to set first the breakpoint, as GDB prompt would not come back if I run emacs.
> >
> > OK, here it is attached.
>
> Thanks.
>
> Earlier, asked when was your previous build, where this problem didn't
> show. I don't think you answered that. Can you please provide that
> information?
<DEV> root [ /sources/emacs ]# git reflog
d66dcde HEAD@{0}: pull: Fast-forward -- that is
from today, I do not have it.
6dc5d45 HEAD@{1}: pull: Fast-forward -- that one
is when I complained about the bug, I have tried
to compile ImageMagick, but found out that it does
not work with version 7, only version 6, then I
observed that I cannot work stable with
emacsclient
2c87aab HEAD@{2}: pull: Fast-forward, that one I
did not test much, as I quickly compiled the
ImageMagick after 1-2 days.
7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
the version that worked without problems.
And all below versions worked without this frame
disappearing.
d715e6d HEAD@{4}: pull: Fast-forward
d812d20 HEAD@{5}: clone: from git://git.sv.gnu.org/emacs.git
I am not that much user of Git, but I would go
back to one of those versions, maybe you can tell
me how.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 23:26:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat, Jul 29, 2017 at 12:23:21AM +0300, Jean Louis wrote:
> 7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
> the version that worked without problems.
I have done
git checkout 7dd72d7
and then re-compiled, and I see the bug is still
appearing, frame is sometimes cancelled or broken,
does not appear.
I was searching on Internet and found this:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2007-08/msg00066.html
and then I am thinking, I have changed my default
font, and increased it. Maybe it is related to a
font.
As in that version 7dd72d7 I had other font
settings.
Now I just use default font, enlarged. I will try
to reset the font back, to see how it works.
Basic default face.
[X] Font Family: DejaVu Sans Mono
[X] Font Foundry: unknown
[X] Width: Value Menu medium
[X] Height: Value Menu Height in 1/10 pt: 173
[X] Weight: Value Menu medium
[X] Slant: Value Menu normal
[X] Underline: Value Menu Off
[X] Overline: Value Menu Off
[X] Strike-through: Value Menu Off
[X] Box around text: Value Menu Off
[X] Inverse-video: Value Menu Off
[X] Foreground: black Choose (sample)
[X] Background: white Choose (sample)
[X] Stipple: Value Menu None
[X] Inherit:
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 28 Jul 2017 23:40:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 29, 2017 at 12:23:21AM +0300, Jean Louis wrote:
> 7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
> the version that worked without problems.
>
> And all below versions worked without this frame
> disappearing.
Just to confirm that even above version has that bug. It was stable
before.
I have tried running emacs without ~/.emacs so it is not about my
fonts, faces, or settings, each few times frame is still not
appearing with BadPixmap error and request 55.
I will try tomorrow to go back to these versions below.
> d715e6d HEAD@{4}: pull: Fast-forward
> d812d20 HEAD@{5}: clone: from git://git.sv.gnu.org/emacs.git
>
> I am not that much user of Git, but I would go
> back to one of those versions, maybe you can tell
> me how.
>
> Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 29 Jul 2017 06:30:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 29 Jul 2017 02:31:23 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 27816 <at> debbugs.gnu.org
>
> On Sat, Jul 29, 2017 at 12:23:21AM +0300, Jean Louis wrote:
> > 7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
> > the version that worked without problems.
> >
> > And all below versions worked without this frame
> > disappearing.
>
> Just to confirm that even above version has that bug. It was stable
> before.
>
> I have tried running emacs without ~/.emacs so it is not about my
> fonts, faces, or settings, each few times frame is still not
> appearing with BadPixmap error and request 55.
It could be that you have updated something else on your system, not
just Emacs's sources, and that indirectly caused the problem even in
builds that previously worked well. If that is the case, it might
mean the problem which causes this is not due to some recent change in
Emacs, it was always there.
With that in mind, can you describe the sequence of actions that you
are using, after which these errors usually appear? Also, are these
errors 100% reproducible, if you replay the same actions , or do they
appear only sometimes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 29 Jul 2017 07:40:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 29, 2017 at 09:29:09AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Jul 2017 02:31:23 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 27816 <at> debbugs.gnu.org
> >
> > On Sat, Jul 29, 2017 at 12:23:21AM +0300, Jean Louis wrote:
> > > 7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
> > > the version that worked without problems.
> > >
> > > And all below versions worked without this frame
> > > disappearing.
> >
> > Just to confirm that even above version has that bug. It was stable
> > before.
> >
> > I have tried running emacs without ~/.emacs so it is not about my
> > fonts, faces, or settings, each few times frame is still not
> > appearing with BadPixmap error and request 55.
>
> It could be that you have updated something else on your system, not
> just Emacs's sources, and that indirectly caused the problem even in
> builds that previously worked well. If that is the case, it might
> mean the problem which causes this is not due to some recent change in
> Emacs, it was always there.
I did not update anything but ImageMagick, which anyway is not
compiled in Emacs, as it is version 7.
My system is not a distribution, and there are no automatic updates,
all tracking is in my head.
> With that in mind, can you describe the sequence of actions that you
> are using, after which these errors usually appear? Also, are these
> errors 100% reproducible, if you replay the same actions , or do they
> appear only sometimes?
Yes, I can describe it.
Emacs is run as daemon by S6 supervision suite, through screen, as
below, nothing changed there since many months, this 2017 year.
I am connecting to emacs by the emacsclient, and the script below. I
had full stability until last 2 attempts to compile it with
ImageMagick, when I pulled last versions.
I am just about to try the one version before.
#!/bin/bash
SERVER=/home/data1/protected/tmp/emacs1001/server
if [ -e $SERVER ]; then
if [ $DISPLAY ];
then exec emacs-client-x "$@" > /dev/null 2>&1 &
else emacs-client "$@"; fi
else zile "$@";
fi
#!/bin/execlineb -P
if { s6-test -d /home/data1/protected/Work }
s6-setuidgid admin
backtick -n HOME { homeof admin }
backtick -n PATH { echo "/home/data1/protected/Programming/perl5/bin:/home/data1/protected/bin:/home/data1/protected/bin/rcd:/home/data1/protected/.local/bin:/home/data1/protected/bin:/home/data1/protected/perl5/bin:/home/data1/protected/bin:/home/data1/protected/bin/rcd:/home/data1/protected/.local/bin:/usr/local/bin:/bin:/usr/bin:/opt/texlive/2015/bin/x86_64-linux:/opt/jdk/bin:/opt/qt4/bin:/opt/qt5/bin:/usr/libexec:/opt/rakudo-star-2016.07/bin:/opt/rakudo-star-2016.07/share/perl6/site/bin:/home/data1/protected/Programming/git/fgallery:/usr/libexec:/opt/rakudo-star-2016.07/bin:/opt/rakudo-star-2016.07/share/perl6/site/bin:/home/data1/protected/Programming/git/fgallery" }
backtick -n MAILDIR { echo "/home/data1/protected/Maildir" }
backtick -n LC_ALL { echo "en_US.UTF-8" }
backtick -n TMPDIR { echo "/home/data1/protected/tmp" }
/usr/bin/screen -l -S emacs -D -m --
/usr/bin/emacs --user admin --chdir /home/data1/protected
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 29 Jul 2017 07:50:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 29, 2017 at 09:29:09AM +0300, Eli Zaretskii wrote:
> With that in mind, can you describe the sequence of actions that you
> are using, after which these errors usually appear? Also, are these
> errors 100% reproducible, if you replay the same actions , or do they
> appear only sometimes?
In last 2 previous versions it appears each 4th or 5th time, not
equally repetitive.
I am not sure if I am using correctly git checkout to try earlier
version. Today I tried it for third time, back in time, and this
emacs-repository-version d715e6d8c6a7f3507f4faca0961ac87d58fbfab8 is
still having the same problem.
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. Was not there before we started conversation and in the version
I used last.
I can just say that in this version
d715e6d8c6a7f3507f4faca0961ac87d58fbfab8, the bug appeared one time
only out of 30-40 times.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 29 Jul 2017 07:55:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello,
I was mistaken, it appears also in this emacs-repository-version
d715e6d8c6a7f3507f4faca0961ac87d58fbfab8
all over again.
On Sat, Jul 29, 2017 at 09:29:09AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Jul 2017 02:31:23 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 27816 <at> debbugs.gnu.org
> >
> > On Sat, Jul 29, 2017 at 12:23:21AM +0300, Jean Louis wrote:
> > > 7dd72d7 HEAD@{3}: pull: Fast-forward -- this is
> > > the version that worked without problems.
> > >
> > > And all below versions worked without this frame
> > > disappearing.
> >
> > Just to confirm that even above version has that bug. It was stable
> > before.
> >
> > I have tried running emacs without ~/.emacs so it is not about my
> > fonts, faces, or settings, each few times frame is still not
> > appearing with BadPixmap error and request 55.
>
> It could be that you have updated something else on your system, not
> just Emacs's sources, and that indirectly caused the problem even in
> builds that previously worked well. If that is the case, it might
> mean the problem which causes this is not due to some recent change in
> Emacs, it was always there.
>
> With that in mind, can you describe the sequence of actions that you
> are using, after which these errors usually appear? Also, are these
> errors 100% reproducible, if you replay the same actions , or do they
> appear only sometimes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 16:21:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
My configuration of GNU Emacs is following:
./configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa --with-modules --with-x-toolkit=lucid --without-gconf --without-gsettings --without-libsystemd --without-dbus --without-pop --with-mailutils --without-imagemagick --with-x
I am still getting:
X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
And I have tried starting Emacs daemon in background without my
~/.emacs so it is still happening without custom configuration.
I have also tested it on different Window Managers.
emacsclient is basically remaining in memory as process, but the frame
is disappearing.
It is annoying as it makes programs wait on emacs client to come back,
as it blocks the console, right? Because it blocks the console, the
frame disappeared, the emacs client runs in memory but is not coming
back. Then I have to kill $(pgrep emacsclient) to make it work again.
Do you think that reason for that can be that I use lucid kit?
The reason that I use the lucid kit is because there was similar bug
that Emacs daemon was crushing in the GTK kit. Lucid kit is much more
stable for me.
Now I cannot understand what happened that it started showing this
error, it is being shown in each 4th 5th or so attempt to spawn
emacsclient.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 18:52:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 2 Aug 2017 19:12:30 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
>
> My configuration of GNU Emacs is following:
>
> ./configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa --with-modules --with-x-toolkit=lucid --without-gconf --without-gsettings --without-libsystemd --without-dbus --without-pop --with-mailutils --without-imagemagick --with-x
>
> I am still getting:
>
> X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
>
> And I have tried starting Emacs daemon in background without my
> ~/.emacs so it is still happening without custom configuration.
Please describe the sequence of actions leading to the problem in more
detail. Here's what you said about that last time:
> 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.
This is not detailed enough for me to understand what is going on. I
presume that mutt somehow invokes emacsclient and you then expect
Emacs to allow you to edit the response to an email message before
sending it. But even if that guess is correct, it doesn't say whether
emacsclient is invoked to open a new frame or reuse an old frame,
whether that frame is a GUI frame or a text-mode frame, and whether
any other Emacs frames existed before the invocation of emacsclient
and were supposed to remain after you finish editing the response.
Btw, does this happen only when emacsclient is invoked from mutt, or
also with other programs? What if you invoke emacsclient from the
shell prompt -- does the problem happen if you invoke it several times
in a row?
Also, are you sure the version of emacsclient that is invoked belongs
to the version of Emacs which is run in the daemon mode?
And finally, if you start Emacs not in daemon mode and then use mutt
as you normally do with daemon, does the problem persist or does it go
away?
> emacsclient is basically remaining in memory as process, but the frame
> is disappearing.
So Emacs now runs without any frames displayed?
> It is annoying as it makes programs wait on emacs client to come back,
> as it blocks the console, right?
That depends how emacsclient is invoked. But if you invoke it from
mutt to edit a response, then you must let it block mutt, because mutt
cannot proceed with sending your response until Emacs is done editing
it.
> Do you think that reason for that can be that I use lucid kit?
I very much doubt that.
> Now I cannot understand what happened that it started showing this
> error, it is being shown in each 4th 5th or so attempt to spawn
> emacsclient.
Something has changed on your system, it seems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 19:33:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Dear Eli,
Thank you so far. See below my answers.
On Wed, Aug 02, 2017 at 09:51:13PM +0300, Eli Zaretskii wrote:
> > ./configure
> --prefix=/package/text/emacs-26.0.50
> --with-sound=alsa --with-modules
> --with-x-toolkit=lucid --without-gconf
> --without-gsettings --without-libsystemd
> --without-dbus --without-pop --with-mailutils
> --without-imagemagick --with-x
I will try changing the lucid to gtk kit to see if
it is happening again.
> > I am still getting:
> >
> > X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
> >
> > And I have tried starting Emacs daemon in background without my
> > ~/.emacs so it is still happening without custom configuration.
>
> Please describe the sequence of actions leading to the problem in more
> detail. Here's what you said about that last time:
>
> > 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.
> What if you invoke emacsclient from the shell
> prompt -- does the problem happen if you invoke
> it several times in a row?
Exactly like that, it happens if I invoke it from
terminal.
Also if I invoke it directly on keypress from
Window Manager or through mutt.
> Also, are you sure the version of emacsclient
> that is invoked belongs to the version of Emacs
> which is run in the daemon mode?
Yes, very sure. I am running
emacs-repository-version
"cf1da46761675f1886e54765fa213c7bd7d93437"
And emacs is then in /package/text/emacs/ and
emacs client is then linked to the version I am
running:
admin-> ls -l /usr/bin/emacsclient
lrwxrwxrwx 1 root root 40 Aug 2 18:55 /usr/bin/emacsclient -> ../../package/text/emacs/bin/emacsclient
and because it is in /package/text/emacs/ it
belongs to same version.
> And finally, if you start Emacs not in daemon
> mode and then use mutt as you normally do with
> daemon, does the problem persist or does it go
> away?
You mean if I run emacs without daemon? There is no problem at all.
But due to loading times, and configuration, it is not usable.
> > emacsclient is basically remaining in memory as process, but the frame
> > is disappearing.
>
> So Emacs now runs without any frames displayed?
Emacs runs all the time, as main program under screen, I can access it
through screen.
The problem is also happening when I do not run it under screen, I can
run it as user.
If there is no GUI frame, and I wish to invoke it by emacsclient, each
few times, the instance failes, GUI frame disappears, but the
emacsclient still runs in memory, until I kill it.
> > Now I cannot understand what happened that it started showing this
> > error, it is being shown in each 4th 5th or so attempt to spawn
> > emacsclient.
>
> Something has changed on your system, it seems.
I do not have dsitribution and did not update system in any manner,
neither touched X Window or similar. I have updated security
certificates, just nothing special on the system.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 22:06:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed, Aug 02, 2017 at 09:51:13PM +0300, Eli Zaretskii wrote:
> > My configuration of GNU Emacs is following:
> >
> > ./configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa --with-modules --with-x-toolkit=lucid --without-gconf --without-gsettings --without-libsystemd --without-dbus --without-pop --with-mailutils --without-imagemagick --with-x
> >
> > I am still getting:
> >
> > X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
I have re-compiled Emacs with just plain
./configure, and I am not experiencing that bug.
I will try it again just with lucid flag, to see
later does it happen again.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 22:48:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Wed, Aug 02, 2017 at 09:51:13PM +0300, Eli Zaretskii wrote:
> > My configuration of GNU Emacs is following:
> >
> > ./configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa --with-modules --with-x-toolkit=lucid --without-gconf --without-gsettings --without-libsystemd --without-dbus --without-pop --with-mailutils --without-imagemagick --with-x
> >
> > I am still getting:
> >
> > X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
I have now discovered that if I compile it with
Lucid, that bug appears:
./configure --prefix=/package/text/emacs-26.0.50 --with-x-toolkit=lucid
and if not, there is no bug, with GTK.
I like Lucid kit more than GTK, but now I am
forced to use GTK for stability.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 02 Aug 2017 23:34:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
I have found what is wrong and how I did not see
that bug earlier. See below.
On Wed, Aug 02, 2017 at 09:51:13PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 2 Aug 2017 19:12:30 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> debbugs.gnu.org
> >
> > My configuration of GNU Emacs is following:
> >
> > ./configure --prefix=/package/text/emacs-26.0.50 --with-sound=alsa --with-modules --with-x-toolkit=lucid --without-gconf --without-gsettings --without-libsystemd --without-dbus --without-pop --with-mailutils --without-imagemagick --with-x
> >
> > I am still getting:
> >
> > X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
I have now recompiled Emacs with Lucid toolkit.
What I remember is that I used it for months
without the scrollbar, to spare the space on
screen.
Recently, I started using it with the default
option, so scrollbar is on the left in Lucid kit
(I guess so).
I have tested it now on:
emacs-repository-version
"cf1da46761675f1886e54765fa213c7bd7d93437"
with Lucid tool kit.
I found out, if I turn off the scroll bar, the
emacsclient invoked frames appear without
problems.
If I turn on scroll bar, on left or right side, I
get that bug message.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 03:26:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 2 Aug 2017 22:31:58 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, 27816 <at> 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...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 05:06:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Good day,
On Thu, Aug 03, 2017 at 06:25:30AM +0300, Eli Zaretskii wrote:
> 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?
1) first in terminal: $ emacs -Q -nw
2) I evaluate (server-start) in *scratch*
3) In other terminal I write: $ emacsclient -s tmp/emacs1001/server -c
7) On 7th attempt the frame did not appear, and terminal remained
blocked waiting for emacsclient to comeback
> Btw, Jean, do you have any Emacs-related settings in your X resources?
> (Although -Q should bypass those as well, AFAIR...)
I do not have.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 09:05:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 27816 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I can give the following additional information on this:
With a Lucid build from 23.8.2014 I get an incompletely drawn frame
(screenshot attached). Clearly, drawing the scroll bar has not finished
yet. A screenshot of a complete frame is attached for comparison. In
the terminal Emacs the message
get-device-terminal: Display :0.0 does not exist
is displayed.
With a build from 9.11.2014 I get the same behavior but with the
meanwhile well-known message:
X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
In addition, the Emacs process consumes all CPU power it can get.
With current master the client frame is shown for a short moment and
then disappears. The Emacs process does not stall.
In all cases, the problem occurs reliably - on the average about every
fifth call of emacsclient. Lucid without toolkit scrollbars doesn't
build here any more, so far no idea why [does anyone grok ...
In file included from ./string.h:49:0,
from ../../lib/explicit_bzero.c:28:
./stddef.h:93:3: error: conflicting types for ‘max_align_t’
In file included from ./stddef.h:55:0,
from ./string.h:49,
from ../../lib/explicit_bzero.c:28:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:426:3: note: previous declaration of ‘max_align_t’ was here
make[1]: *** [explicit_bzero.o] Fehler 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
In file included from ./unistd.h:56:0,
from ../../lib/fcntl.c:28:
./stddef.h:93:3: error: conflicting types for ‘max_align_t’
In file included from ./stddef.h:55:0,
from ./unistd.h:56,
from ../../lib/fcntl.c:28:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:426:3: note: previous declaration of ‘max_align_t’ was here
... I haven't built this for years?]. A motif build of master doesn't
exhibit this behavior but gets the Emacs process aborted here around
every seventh invocation of the client. A gtk build exhibits no
problems AFAICT and a build without X toolkit support works well too.
BTW, I never use emacsclient and have no idea how to use it. Is there a
way to stop the server from the starting emacs?
martin
[incomplete frame - 2017-08-03.png (image/png, attachment)]
[complete frame - 2017-08-03.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 16:11:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 3 Aug 2017 07:59:41 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, martin rudalics <rudalics <at> gmx.at>,
> 27816 <at> debbugs.gnu.org
>
> > $ emacs -Q -nw
> > $ emacsclient -s tmp/emacs1001/server -c
> >
> > Jean, does the above indeed reproduce the problem?
>
> 1) first in terminal: $ emacs -Q -nw
>
> 2) I evaluate (server-start) in *scratch*
>
> 3) In other terminal I write: $ emacsclient -s tmp/emacs1001/server -c
>
> 7) On 7th attempt the frame did not appear, and terminal remained
> blocked waiting for emacsclient to comeback
Right, that's what I meant. Sorry for omitting some intermediate
steps.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 16:26:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 03 Aug 2017 11:04:00 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 27816 <at> debbugs.gnu.org
>
> With a build from 9.11.2014 I get the same behavior but with the
> meanwhile well-known message:
>
> X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55
>
> In addition, the Emacs process consumes all CPU power it can get.
>
>
> With current master the client frame is shown for a short moment and
> then disappears. The Emacs process does not stall.
Could any of this be related to the change whereby we no longer wait
for the frame to become visible?
> In all cases, the problem occurs reliably - on the average about every
> fifth call of emacsclient.
If you run Emacs in X synchronized mode and put a breakpoint on
x_error_quitter, can you see why the problem happens? Which picmap
parameter is invalid?
> Lucid without toolkit scrollbars doesn't
> build here any more, so far no idea why [does anyone grok ...
>
> In file included from ./string.h:49:0,
> from ../../lib/explicit_bzero.c:28:
> ./stddef.h:93:3: error: conflicting types for ‘max_align_t’
> In file included from ./stddef.h:55:0,
> from ./string.h:49,
> from ../../lib/explicit_bzero.c:28:
> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:426:3: note: previous declaration of ‘max_align_t’ was here
> make[1]: *** [explicit_bzero.o] Fehler 1
> make[1]: *** Warte auf noch nicht beendete Prozesse...
> In file included from ./unistd.h:56:0,
> from ../../lib/fcntl.c:28:
> ./stddef.h:93:3: error: conflicting types for ‘max_align_t’
> In file included from ./stddef.h:55:0,
> from ./unistd.h:56,
> from ../../lib/fcntl.c:28:
> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:426:3: note: previous declaration of ‘max_align_t’ was here
Sounds like some Gnulib-related issue. Perhaps Paul could help figure
this out.
> BTW, I never use emacsclient and have no idea how to use it. Is there a
> way to stop the server from the starting emacs?
I don't understand the question. When Emacs starts, the server is not
started automatically, so I'm unsure what is it that you want to do.
Please tell me what I missed.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 16:45:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Lucid without toolkit scrollbars doesn't
>> build here any more, so far no idea why [does anyone grok ...
[...]
> Sounds like some Gnulib-related issue. Perhaps Paul could help figure
> this out.
FWIW, works fine here. If it still happens in a clean build, I suggest
opening a separate report with system information, and attached
compressed config and build logs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 17:58:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Could any of this be related to the change whereby we no longer wait
> for the frame to become visible?
You mean that Emacs now doesn't consume CPU cycles any more? In any
case, I think that the problem has existed ever since. It just
manifests itself in different ways. And it would be nice if someone
else who builds Lucid tried the scenario. It's even simpler than Jean
Louis describes it:
(1) In one terminal do emacs -Q -nw
(2) M-x server-start
(3) In another terminal do emacsclient -c
(4) In the GUI frame do C-x 5 0 and repeat (3) and (4) at least five
times.
> If you run Emacs in X synchronized mode and put a breakpoint on
> x_error_quitter, can you see why the problem happens? Which picmap
> parameter is invalid?
I'll try to do that as soon as I understand how it works and how to
debug it. Also IIRC synchronized mode didn't always work 100% reliably
here. From the pngs it seems obvious that the arrows above and below
the slider didn't get drawn.
>> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:426:3: note: previous declaration of ‘max_align_t’ was here
>
> Sounds like some Gnulib-related issue. Perhaps Paul could help figure
> this out.
I suppose some leftovers in the build directory. I have to build from
scratch.
>> BTW, I never use emacsclient and have no idea how to use it. Is there a
>> way to stop the server from the starting emacs?
>
> I don't understand the question. When Emacs starts, the server is not
> started automatically, so I'm unsure what is it that you want to do.
> Please tell me what I missed.
The doc-string of ‘server-start’ says that this would "Allow this Emacs
process to be a server for client processes". How can I "Stop this
Emacs process to be a server for client processes"? Frankly I have no
idea what emacsclient is, how it works and how it interacts with the
server.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Thu, 03 Aug 2017 18:37:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 03 Aug 2017 19:56:23 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: bugs <at> gnu.support, 27816 <at> debbugs.gnu.org
>
> The doc-string of ‘server-start’ says that this would "Allow this Emacs
> process to be a server for client processes". How can I "Stop this
> Emacs process to be a server for client processes"?
M-x server-force-delete RET
> Frankly I have no idea what emacsclient is, how it works and how it
> interacts with the server.
See server.el and the emacsclient sources, I think they are pretty
self explanatory, at least as far as the concept goes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 04 Aug 2017 08:55:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> If you run Emacs in X synchronized mode and put a breakpoint on
> x_error_quitter, can you see why the problem happens? Which picmap
> parameter is invalid?
No idea how to run a TTY Emacs in X synchronized mode. Anyway the
backtrace without doing that seems quite clear
#0 x_error_quitter (display=0xea2a40, event=0x7fffb0f542c0) at ../../src/xterm.c:9856
#1 0x000000000054763f in x_error_handler (display=0xea2a40, event=0x7fffb0f542c0) at ../../src/xterm.c:9828
#2 0x00007f8dfad1229a in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007f8dfad0f5c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007f8dfad0f605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f8dfad101f8 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007f8dfad05a1d in XQueryColor () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007f8dfbaf25fc in Xaw3dComputeTopShadowRGB () from /usr/lib/x86_64-linux-gnu/libXaw3d.so.6
#8 0x00007f8dfbaf26f0 in ?? () from /usr/lib/x86_64-linux-gnu/libXaw3d.so.6
#9 0x00007f8dfbaf2b5a in ?? () from /usr/lib/x86_64-linux-gnu/libXaw3d.so.6
#10 0x00007f8dfb657490 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#11 0x00007f8dfb65745a in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#12 0x00007f8dfb657e5f in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#13 0x00007f8dfb6582ab in _XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#14 0x00007f8dfb6585ce in XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#15 0x000000000053eeef in x_create_toolkit_scroll_bar (f=0x15cb3f0, bar=0x15f1a88) at ../../src/xterm.c:6005
#16 0x000000000053fbc1 in x_scroll_bar_create (w=0x15e36f0, top=667, left=1, width=16, height=18, horizontal=false) at ../../src/xterm.c:6492
#17 0x00000000005405f4 in XTset_vertical_scroll_bar (w=0x15e36f0, portion=0, whole=0, position=0) at ../../src/xterm.c:6746
#18 0x000000000046b431 in set_vertical_scroll_bar (w=0x15e36f0) at ../../src/xdisp.c:16352
#19 0x000000000046fabc in redisplay_window (window=..., just_this_one_p=false) at ../../src/xdisp.c:17506
#20 0x0000000000465a20 in redisplay_window_0 (window=...) at ../../src/xdisp.c:14778
#21 0x000000000062e5f7 in internal_condition_case_1 (bfun=0x4659de <redisplay_window_0>, arg=..., handlers=..., hfun=0x4659a6 <redisplay_window_error>) at ../../src/eval.c:1343
#22 0x000000000046597c in redisplay_windows (window=...) at ../../src/xdisp.c:14758
#23 0x0000000000464373 in redisplay_internal () at ../../src/xdisp.c:14247
#24 0x000000000046505a in redisplay_preserve_echo_area (from_where=12) at ../../src/xdisp.c:14577
#25 0x0000000000693238 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5620
#26 0x000000000041e817 in sit_for (timeout=..., reading=true, display_option=1) at ../../src/dispnew.c:5763
#27 0x000000000057bcfc in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffb0f5968f, end_time=0x0) at ../../src/keyboard.c:2724
#28 0x000000000058b988 in read_key_sequence (keybuf=0x7fffb0f59830, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9151
#29 0x0000000000577dea in command_loop_1 () at ../../src/keyboard.c:1372
#30 0x000000000062e51d in internal_condition_case (bfun=0x5779ad <command_loop_1>, handlers=..., hfun=0x576fe0 <cmd_error>) at ../../src/eval.c:1319
#31 0x000000000057759e in command_loop_2 (ignore=...) at ../../src/keyboard.c:1114
#32 0x000000000062da19 in internal_catch (tag=..., func=0x577575 <command_loop_2>, arg=...) at ../../src/eval.c:1084
#33 0x0000000000577540 in command_loop () at ../../src/keyboard.c:1093
#34 0x0000000000576ae7 in recursive_edit_1 () at ../../src/keyboard.c:699
#35 0x0000000000576cce in Frecursive_edit () at ../../src/keyboard.c:770
#36 0x00000000005749d6 in main (argc=3, argv=0x7fffb0f59d18) at ../../src/emacs.c:1706
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
and is, BTW, the same as in the 2014 build. Apparently, the shadow
calculations for the Xaw3D scroll bars, when done from a TTY-started
server, are sometimes not digested by X11. I see no problems with a
GUI-started server.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 04 Aug 2017 08:55:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> M-x server-force-delete RET
Thanks.
> See server.el and the emacsclient sources, I think they are pretty
> self explanatory, at least as far as the concept goes.
In the light of the present bug: Do you see any conceptual problems
starting a GUI emacsclient from a TTY-started server?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 04 Aug 2017 09:51:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 04 Aug 2017 10:54:03 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: bugs <at> gnu.support, 27816 <at> debbugs.gnu.org
>
> > If you run Emacs in X synchronized mode and put a breakpoint on
> > x_error_quitter, can you see why the problem happens? Which picmap
> > parameter is invalid?
>
> No idea how to run a TTY Emacs in X synchronized mode.
etc/DEBUG suggests to evaluate (x-synchronize t).
> Apparently, the shadow calculations for the Xaw3D scroll bars, when
> done from a TTY-started server, are sometimes not digested by X11.
Can you try figuring out why is that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 04 Aug 2017 09:52:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 04 Aug 2017 10:54:21 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: bugs <at> gnu.support, 27816 <at> debbugs.gnu.org
>
> In the light of the present bug: Do you see any conceptual problems
> starting a GUI emacsclient from a TTY-started server?
There shouldn't be any, not in principle. It's possible that some
initialization is missing somewhere, but we need to identify that
first.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 05 Aug 2017 12:48:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> etc/DEBUG suggests to evaluate (x-synchronize t).
Gets me
Debugger entered--Lisp error: (error "X windows are not in use or not initialized")
x-synchronize(t)
here.
>> Apparently, the shadow calculations for the Xaw3D scroll bars, when
>> done from a TTY-started server, are sometimes not digested by X11.
>
> Can you try figuring out why is that?
I have no idea how to do that. Passing no arguments to XtCreateWidget
doesn't help so IIUC the problem is somewhere in between
Xaw3dComputeTopShadowRGB and XQueryColor but maybe someone has a better
explanation.
BTW, this behavior has been reported in bug#5802 where it says:
When the lucid version, emacs does not crash, but for some reason,
when I run the emacsclient frame-creating loop that I described
previously, sometimes the client frame disappears as soon as it
appears, and I assumed that a crash had occurred. But in this case,
emacs does not crash, and I only get the problem in a loop like this.
Simply running "emacsclient -c" manually over and over at the
command-line never causes a frame to disappear. So, I think I will
move forward using the lucid version, and you can mark this as a GTK
problem.
And obviously this is bug#23499 where you stated:
Error code 4 is BadPixmap, according to my references. I hope some X
expert will chime in and tell why this happens. (I actually don't
understand why we try to create the scroll bar when the frame is
iconified.)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 05 Aug 2017 12:57:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 05 Aug 2017 14:46:12 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: bugs <at> gnu.support, 27816 <at> debbugs.gnu.org
>
> I have no idea how to do that. Passing no arguments to XtCreateWidget
> doesn't help so IIUC the problem is somewhere in between
> Xaw3dComputeTopShadowRGB and XQueryColor but maybe someone has a better
> explanation.
>
>
> BTW, this behavior has been reported in bug#5802 where it says:
>
> When the lucid version, emacs does not crash, but for some reason,
> when I run the emacsclient frame-creating loop that I described
> previously, sometimes the client frame disappears as soon as it
> appears, and I assumed that a crash had occurred. But in this case,
> emacs does not crash, and I only get the problem in a loop like this.
> Simply running "emacsclient -c" manually over and over at the
> command-line never causes a frame to disappear. So, I think I will
> move forward using the lucid version, and you can mark this as a GTK
> problem.
>
> And obviously this is bug#23499 where you stated:
>
> Error code 4 is BadPixmap, according to my references. I hope some X
> expert will chime in and tell why this happens. (I actually don't
> understand why we try to create the scroll bar when the frame is
> iconified.)
Then I guess this should go in etc/PROBLEMS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 05 Aug 2017 18:06:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sat, Aug 05, 2017 at 02:46:12PM +0200, martin rudalics wrote:
> > etc/DEBUG suggests to evaluate (x-synchronize t).
>
> Gets me
>
> Debugger entered--Lisp error: (error "X windows are not in use or not initialized")
> x-synchronize(t)
>
> here.
You can start emacs server in terminal, and then
open at least one GUI frame and do (x-synchronize
t), it works that way.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 05 Aug 2017 18:43:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 27816 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> You can start emacs server in terminal, and then
> open at least one GUI frame and do (x-synchronize
> t), it works that way.
As far as I can tell from the code, this only affects the current
terminal (GUI frame). What seems to work is this:
emacs -Q -nw --eval '(setq x-command-line-resources "emacs.synchronous: true")'
I've tried the recipe --without-toolkit-scroll-bars; the error does not
occur under this configuration. There is some other minor trouble (not
really related to this bug I think): the scrollbar does not get drawn
(the space where it should be is all white instead) when first opening
the frame, unless I've set synchronous mode as above.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 05 Aug 2017 20:12:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 27816 <at> debbugs.gnu.org (full text, mbox):
I don't get the Xaw3dComputeTopShadowRGB in my backtrace like Martin does:
Thread 1 "emacs" hit Breakpoint 3, x_error_quitter (display=0x2ea8ff0, event=0x7fffffff8df0)
at ../../emacs-master/src/xterm.c:9849
9849 if (event->error_code == BadName)
(gdb) bt
#0 0x000000000054b168 in x_error_quitter (display=0x2ea8ff0, event=0x7fffffff8df0)
at ../../emacs-master/src/xterm.c:9849
#1 0x000000000054b148 in x_error_handler (display=0x2ea8ff0, event=0x7fffffff8df0)
at ../../emacs-master/src/xterm.c:9828
#2 0x00007ffff66e36fd in _XError () at /usr/lib/libX11.so.6
#3 0x00007ffff66e0627 in () at /usr/lib/libX11.so.6
#4 0x00007ffff66e06e5 in () at /usr/lib/libX11.so.6
#5 0x00007ffff66e15f8 in _XReply () at /usr/lib/libX11.so.6
#6 0x00007ffff66dcfed in XSync () at /usr/lib/libX11.so.6
#7 0x00007ffff66dd08b in () at /usr/lib/libX11.so.6
#8 0x00007ffff66c01da in XCreateGC () at /usr/lib/libX11.so.6
#9 0x00007ffff7039d2c in XtAllocateGC () at /usr/lib/libXt.so.6
#10 0x00007ffff74ce84a in () at /usr/lib/libXaw.so.7
#11 0x00007ffff74cecfc in () at /usr/lib/libXaw.so.7
#12 0x00007ffff703192c in () at /usr/lib/libXt.so.6
#13 0x00007ffff70322c8 in () at /usr/lib/libXt.so.6
#14 0x00007ffff7032718 in _XtCreateWidget () at /usr/lib/libXt.so.6
#15 0x00007ffff70329fd in XtCreateWidget () at /usr/lib/libXt.so.6
#16 0x0000000000542d6f in x_create_toolkit_scroll_bar (f=0x15c7c30 <bss_sbrk_buffer+8094096>, bar=0x1351fa8 <bss_sbrk_buffer+5514504>) at ../../emacs-master/src/xterm.c:6005
#17 0x00000000005438e6 in x_scroll_bar_create (w=0x1676c30 <bss_sbrk_buffer+8810896>, top=37, left=1, width=16, height=768, horizontal=false) at ../../emacs-master/src/xterm.c:6492
#18 0x00000000005442c0 in XTset_vertical_scroll_bar (w=0x1676c30 <bss_sbrk_buffer+8810896>, portion=145, whole=145, position=0) at ../../emacs-master/src/xterm.c:6746
#19 0x000000000046e131 in set_vertical_scroll_bar (w=0x1676c30 <bss_sbrk_buffer+8810896>)
at ../../emacs-master/src/xdisp.c:16351
#20 0x0000000000472782 in redisplay_window (window=XIL(0x1676c35), just_this_one_p=false)
at ../../emacs-master/src/xdisp.c:17506
#21 0x0000000000468921 in redisplay_window_0 (window=XIL(0x1676c35))
at ../../emacs-master/src/xdisp.c:14778
#22 0x0000000000636815 in internal_condition_case_1 (bfun=0x4688df <redisplay_window_0>, arg=XIL(0x1676c35), handlers=XIL(0xe79df3), hfun=0x4688a7 <redisplay_window_error>)
at ../../emacs-master/src/eval.c:1343
#23 0x000000000046887c in redisplay_windows (window=XIL(0x1676c35))
at ../../emacs-master/src/xdisp.c:14758
#24 0x00000000004672a0 in redisplay_internal () at ../../emacs-master/src/xdisp.c:14247
#25 0x0000000000467f6e in redisplay_preserve_echo_area (from_where=12)
at ../../emacs-master/src/xdisp.c:14577
#26 0x000000000069adbb in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at ../../emacs-master/src/process.c:5620
#27 0x00000000004225fd in sit_for (timeout=make_number(30), reading=true, display_option=1)
at ../../emacs-master/src/dispnew.c:5763
#28 0x000000000058691c in read_char (commandflag=1, map=XIL(0x1745dd3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe28f, end_time=0x0) at ../../emacs-master/src/keyboard.c:2724
#29 0x00000000005960a2 in read_key_sequence (keybuf=0x7fffffffe420, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
at ../../emacs-master/src/keyboard.c:9151
#30 0x0000000000582aaf in command_loop_1 () at ../../emacs-master/src/keyboard.c:1372
#31 0x000000000063673e in internal_condition_case (bfun=0x58267c <command_loop_1>, handlers=XIL(0x51f0), hfun=0x581cd2 <cmd_error>) at ../../emacs-master/src/eval.c:1319
#32 0x0000000000582281 in command_loop_2 (ignore=XIL(0)) at ../../emacs-master/src/keyboard.c:1114
#33 0x0000000000635c7b in internal_catch (tag=XIL(0xc510), func=0x582258 <command_loop_2>, arg=XIL(0))
at ../../emacs-master/src/eval.c:1084
#34 0x0000000000582223 in command_loop () at ../../emacs-master/src/keyboard.c:1093
#35 0x00000000005817e7 in recursive_edit_1 () at ../../emacs-master/src/keyboard.c:699
#36 0x00000000005819c6 in Frecursive_edit () at ../../emacs-master/src/keyboard.c:770
#37 0x000000000057f653 in main (argc=9, argv=0x7fffffffe8f8) at ../../emacs-master/src/emacs.c:1706
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 09:14:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 27816 <at> debbugs.gnu.org (full text, mbox):
>> Debugger entered--Lisp error: (error "X windows are not in use or not initialized")
>> x-synchronize(t)
>>
>> here.
>
> You can start emacs server in terminal, and then
> open at least one GUI frame and do (x-synchronize
> t), it works that way.
Thanks, yes. I earlier got around this by starting the client once and
simply x-synchronizing from there.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 09:14:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> As far as I can tell from the code, this only affects the current
> terminal (GUI frame). What seems to work is this:
>
> emacs -Q -nw --eval '(setq x-command-line-resources "emacs.synchronous: true")'
I wouldn't be too sure about this one.
> I've tried the recipe --without-toolkit-scroll-bars; the error does not
> occur under this configuration. There is some other minor trouble (not
> really related to this bug I think): the scrollbar does not get drawn
> (the space where it should be is all white instead) when first opening
> the frame, unless I've set synchronous mode as above.
I've seen that too. I'm afraid the non-toolkit code has aged much over
the past years. Nobody works on it.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 09:15:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> I don't get the Xaw3dComputeTopShadowRGB in my backtrace like Martin does:
>
> Thread 1 "emacs" hit Breakpoint 3, x_error_quitter (display=0x2ea8ff0, event=0x7fffffff8df0)
> at ../../emacs-master/src/xterm.c:9849
> 9849 if (event->error_code == BadName)
> (gdb) bt
> #0 0x000000000054b168 in x_error_quitter (display=0x2ea8ff0, event=0x7fffffff8df0)
> at ../../emacs-master/src/xterm.c:9849
> #1 0x000000000054b148 in x_error_handler (display=0x2ea8ff0, event=0x7fffffff8df0)
> at ../../emacs-master/src/xterm.c:9828
> #2 0x00007ffff66e36fd in _XError () at /usr/lib/libX11.so.6
> #3 0x00007ffff66e0627 in () at /usr/lib/libX11.so.6
> #4 0x00007ffff66e06e5 in () at /usr/lib/libX11.so.6
> #5 0x00007ffff66e15f8 in _XReply () at /usr/lib/libX11.so.6
> #6 0x00007ffff66dcfed in XSync () at /usr/lib/libX11.so.6
> #7 0x00007ffff66dd08b in () at /usr/lib/libX11.so.6
> #8 0x00007ffff66c01da in XCreateGC () at /usr/lib/libX11.so.6
> #9 0x00007ffff7039d2c in XtAllocateGC () at /usr/lib/libXt.so.6
> #10 0x00007ffff74ce84a in () at /usr/lib/libXaw.so.7
> #11 0x00007ffff74cecfc in () at /usr/lib/libXaw.so.7
> #12 0x00007ffff703192c in () at /usr/lib/libXt.so.6
> #13 0x00007ffff70322c8 in () at /usr/lib/libXt.so.6
> #14 0x00007ffff7032718 in _XtCreateWidget () at /usr/lib/libXt.so.6
> #15 0x00007ffff70329fd in XtCreateWidget () at /usr/lib/libXt.so.6
> #16 0x0000000000542d6f in x_create_toolkit_scroll_bar (f=0x15c7c30 <bss_sbrk_buffer+8094096>, bar=0x1351fa8 <bss_sbrk_buffer+5514504>) at ../../emacs-master/src/xterm.c:6005
> #17 0x00000000005438e6 in x_scroll_bar_create (w=0x1676c30 <bss_sbrk_buffer+8810896>, top=37, left=1, width=16, height=768, horizontal=false) at ../../emacs-master/src/xterm.c:6492
Maybe you should try calling ‘x-synchronize’ first. Without that I can
get all sorts of things like, for example,
#0 x_error_quitter (display=0xe6dd60, event=0x7fffebd72bc0) at ../../src/xterm.c:9855
#1 0x000000000054763f in x_error_handler (display=0xe6dd60, event=0x7fffebd72bc0) at ../../src/xterm.c:9828
#2 0x00007ffa6360729a in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffa636045c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffa63604605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffa63604e95 in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffa635f65ad in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x0000000000545aa4 in XTread_socket (terminal=0x1e23a38, hold_quit=0x7fffebd72e20) at ../../src/xterm.c:9055
#8 0x0000000000585ce8 in gobble_input () at ../../src/keyboard.c:6913
#9 0x00000000005861ff in handle_async_input () at ../../src/keyboard.c:7150
#10 0x000000000058621b in process_pending_signals () at ../../src/keyboard.c:7164
#11 0x000000000058625a in unblock_input_to (level=0) at ../../src/keyboard.c:7179
#12 0x000000000058627d in unblock_input () at ../../src/keyboard.c:7198
#13 0x000000000053fdc6 in x_scroll_bar_create (w=0x156c7d0, top=37, left=1, width=16, height=612, horizontal=false) at ../../src/xterm.c:6575
#14 0x00000000005405f4 in XTset_vertical_scroll_bar (w=0x156c7d0, portion=145, whole=145, position=0) at ../../src/xterm.c:6746
#15 0x000000000046b431 in set_vertical_scroll_bar (w=0x156c7d0) at ../../src/xdisp.c:16352
#16 0x000000000046fabc in redisplay_window (window=..., just_this_one_p=false) at ../../src/xdisp.c:17506
#17 0x0000000000465a20 in redisplay_window_0 (window=...) at ../../src/xdisp.c:14778
#18 0x000000000062e5f7 in internal_condition_case_1 (bfun=0x4659de <redisplay_window_0>, arg=..., handlers=..., hfun=0x4659a6 <redisplay_window_error>) at ../../src/eval.c:1343
#19 0x000000000046597c in redisplay_windows (window=...) at ../../src/xdisp.c:14758
#20 0x0000000000464373 in redisplay_internal () at ../../src/xdisp.c:14247
#21 0x000000000046505a in redisplay_preserve_echo_area (from_where=12) at ../../src/xdisp.c:14577
#22 0x0000000000693238 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5620
#23 0x000000000041e817 in sit_for (timeout=..., reading=true, display_option=1) at ../../src/dispnew.c:5763
#24 0x000000000057bcfc in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffebd778af, end_time=0x0) at ../../src/keyboard.c:2724
#25 0x000000000058b988 in read_key_sequence (keybuf=0x7fffebd77a50, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9151
#26 0x0000000000577dea in command_loop_1 () at ../../src/keyboard.c:1372
#27 0x000000000062e51d in internal_condition_case (bfun=0x5779ad <command_loop_1>, handlers=..., hfun=0x576fe0 <cmd_error>) at ../../src/eval.c:1319
#28 0x000000000057759e in command_loop_2 (ignore=...) at ../../src/keyboard.c:1114
#29 0x000000000062da19 in internal_catch (tag=..., func=0x577575 <command_loop_2>, arg=...) at ../../src/eval.c:1084
#30 0x0000000000577540 in command_loop () at ../../src/keyboard.c:1093
#31 0x0000000000576ae7 in recursive_edit_1 () at ../../src/keyboard.c:699
#32 0x0000000000576cce in Frecursive_edit () at ../../src/keyboard.c:770
#33 0x00000000005749d6 in main (argc=3, argv=0x7fffebd77f38) at ../../src/emacs.c:1706
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
But with ‘x-synchronize’ I reliably get the Xaw3dComputeTopShadowRGB
bug.
BTW could you try this with a motif build? Here this gets me the backtrace
#0 x_error_quitter (display=0x101b690, event=0x7fffaa9f2a60) at ../../src/xterm.c:9855
#1 0x0000000000547477 in x_error_handler (display=0x101b690, event=0x7fffaa9f2a60) at ../../src/xterm.c:9828
#2 0x00007f502555429a in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007f50255515c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007f5025551605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f50255521f8 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007f5025536e79 in XGetGeometry () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007f502638cd41 in size_cascade (cascadebtn=cascadebtn <at> entry=0x1058230) at CascadeB.c:1851
#8 0x00007f502638d713 in Initialize (w_req=0x7fffaa9f2ee0, w_new=0x1058230, args=<optimized out>, num_args=<optimized out>) at CascadeB.c:2448
#9 0x00007f5025e99490 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#10 0x00007f5025e99e5f in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#11 0x00007f5025e9a2ab in _XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#12 0x00007f5025e9a5ce in XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#13 0x00000000006fd413 in make_menu_in_widget (instance=0xf3d6f0, widget=0x116cf10, val=0x114d2f0, keep_first_children=0) at ../../lwlib/lwlib-Xm.c:599
#14 0x00000000006fd3ba in make_menu_in_widget (instance=0xf3d6f0, widget=0x110e890, val=0x1795990, keep_first_children=0) at ../../lwlib/lwlib-Xm.c:597
#15 0x00000000006fdc33 in xm_update_menu (instance=0xf3d6f0, widget=0x110e890, val=0x1d1c5d0, deep_p=1 '\001') at ../../lwlib/lwlib-Xm.c:793
#16 0x00000000006fdf50 in xm_update_one_widget (instance=0xf3d6f0, widget=0x110e890, val=0x1d1c5d0, deep_p=1 '\001') at ../../lwlib/lwlib-Xm.c:879
#17 0x00000000006fb140 in set_one_value (instance=0xf3d6f0, val=0x1d1c5d0, deep_p=1 '\001') at ../../lwlib/lwlib.c:534
#18 0x00000000006fb193 in update_one_widget_instance (instance=0xf3d6f0, deep_p=1 '\001') at ../../lwlib/lwlib.c:554
#19 0x00000000006fb450 in initialize_widget_instance (instance=0xf3d6f0) at ../../lwlib/lwlib.c:633
#20 0x00000000006fb804 in lw_make_widget (id=5, parent=0x7f5018032840, pop_up_p=0 '\000') at ../../lwlib/lwlib.c:771
#21 0x00000000006fb887 in lw_create_widget (type=0x70cb31 "menubar", name=0x70cb31 "menubar", id=5, val=0xf3f990, parent=0x7f5018032840, pop_up_p=0 '\000', pre_activate_cb=0x4aaf1f <popup_activate_callback>, selection_cb=0x4ab096 <menubar_selection_callback>, post_activate_cb=0x4aaf43 <popup_deactivate_callback>, highlight_cb=0x4ab031 <menu_highlight_callback>) at ../../lwlib/lwlib.c:786
#22 0x00000000004abe1d in set_frame_menubar (f=0x15ffe70, first_time=true, deep_p=true) at ../../src/xmenu.c:962
#23 0x00000000004abf56 in initialize_frame_menubar (f=0x15ffe70) at ../../src/xmenu.c:1035
#24 0x000000000055846f in Fx_create_frame (parms=...) at ../../src/xfns.c:3969
#25 0x0000000000633056 in funcall_subr (subr=0x9b1838, numargs=1, args=0x7fffaa9f5b78) at ../../src/eval.c:2815
#26 0x0000000000632bb6 in Ffuncall (nargs=2, args=0x7fffaa9f5b70) at ../../src/eval.c:2740
#27 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffaa9f6320) at ../../src/bytecode.c:629
#28 0x00000000006337da in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffaa9f6318) at ../../src/eval.c:2941
#29 0x0000000000632bfa in Ffuncall (nargs=2, args=0x7fffaa9f6310) at ../../src/eval.c:2742
#30 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffaa9f6c30) at ../../src/bytecode.c:629
#31 0x00000000006337da in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffaa9f6c28) at ../../src/eval.c:2941
#32 0x0000000000632bfa in Ffuncall (nargs=2, args=0x7fffaa9f6c20) at ../../src/eval.c:2742
#33 0x000000000063192b in Fapply (nargs=2, args=0x7fffaa9f6c20) at ../../src/eval.c:2328
#34 0x0000000000632f61 in funcall_subr (subr=0xd5c0e8, numargs=2, args=0x7fffaa9f6c20) at ../../src/eval.c:2795
#35 0x0000000000632bb6 in Ffuncall (nargs=3, args=0x7fffaa9f6c18) at ../../src/eval.c:2740
#36 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffaa9f73d0) at ../../src/bytecode.c:629
#37 0x00000000006337da in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffaa9f73d0) at ../../src/eval.c:2941
#38 0x0000000000632bfa in Ffuncall (nargs=2, args=0x7fffaa9f73c8) at ../../src/eval.c:2742
#39 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffaa9f7bf8) at ../../src/bytecode.c:629
#40 0x00000000006337da in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffaa9f7bf0) at ../../src/eval.c:2941
#41 0x0000000000632bfa in Ffuncall (nargs=2, args=0x7fffaa9f7be8) at ../../src/eval.c:2742
#42 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fffaa9f8358) at ../../src/bytecode.c:629
#43 0x00000000006337da in funcall_lambda (fun=..., nargs=2, arg_vector=0x7fffaa9f8348) at ../../src/eval.c:2941
#44 0x0000000000632bfa in Ffuncall (nargs=3, args=0x7fffaa9f8340) at ../../src/eval.c:2742
#45 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=5, args=0x7fffaa9f8ba0) at ../../src/bytecode.c:629
#46 0x00000000006337da in funcall_lambda (fun=..., nargs=5, arg_vector=0x7fffaa9f8b78) at ../../src/eval.c:2941
#47 0x0000000000632bfa in Ffuncall (nargs=6, args=0x7fffaa9f8b70) at ../../src/eval.c:2742
#48 0x0000000000683abe in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fffaa9f96c8) at ../../src/bytecode.c:629
#49 0x00000000006337da in funcall_lambda (fun=..., nargs=2, arg_vector=0x7fffaa9f96b8) at ../../src/eval.c:2941
#50 0x0000000000632bfa in Ffuncall (nargs=3, args=0x7fffaa9f96b0) at ../../src/eval.c:2742
#51 0x0000000000631e5d in Fapply (nargs=2, args=0x7fffaa9f97c0) at ../../src/eval.c:2371
#52 0x00000000006324e3 in apply1 (fn=..., arg=...) at ../../src/eval.c:2587
#53 0x0000000000694106 in read_process_output_call (fun_and_args=...) at ../../src/process.c:5786
#54 0x000000000062edb3 in internal_condition_case_1 (bfun=0x69407c <read_process_output_call>, arg=..., handlers=..., hfun=0x694108 <read_process_output_error_handler>) at ../../src/eval.c:1343
#55 0x000000000069483f in read_and_dispose_of_process_output (p=0x15b98a0, chars=0x7fffaa9f9900 "-env SSH_AGENT_PID=3503 -env GLADE_PIXMAP_PATH=: -env TERM=xterm -env SHELL=/bin/bash -env XDG_MENU_PREFIX=xfce- -env XDG_SESSION_COOKIE=360407d161edb80c94a79fe552372b03-1502005113.99060-990150677 -en"..., nbytes=2644, coding=0x1c09c50) at ../../src/process.c:5994
#56 0x0000000000694499 in read_process_output (proc=..., channel=8) at ../../src/process.c:5905
#57 0x000000000069394c in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5604
#58 0x000000000041ee77 in sit_for (timeout=..., reading=true, display_option=1) at ../../src/dispnew.c:5763
#59 0x000000000057c3a8 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffaa9fb38f, end_time=0x0) at ../../src/keyboard.c:2724
#60 0x000000000058c034 in read_key_sequence (keybuf=0x7fffaa9fb530, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9151
#61 0x0000000000578496 in command_loop_1 () at ../../src/keyboard.c:1372
#62 0x000000000062ecd9 in internal_condition_case (bfun=0x578059 <command_loop_1>, handlers=..., hfun=0x57768c <cmd_error>) at ../../src/eval.c:1319
#63 0x0000000000577c4a in command_loop_2 (ignore=...) at ../../src/keyboard.c:1114
#64 0x000000000062e1d5 in internal_catch (tag=..., func=0x577c21 <command_loop_2>, arg=...) at ../../src/eval.c:1084
#65 0x0000000000577bec in command_loop () at ../../src/keyboard.c:1093
#66 0x0000000000577193 in recursive_edit_1 () at ../../src/keyboard.c:699
#67 0x000000000057737a in Frecursive_edit () at ../../src/keyboard.c:770
#68 0x0000000000575082 in main (argc=3, argv=0x7fffaa9fba18) at ../../src/emacs.c:1706
Lisp Backtrace:
"x-create-frame" (0xaa9f5b78)
"x-create-frame-with-faces" (0xaa9f6318)
0x1453a50 PVEC_COMPILED
"apply" (0xaa9f6c20)
"frame-creation-function" (0xaa9f73d0)
"make-frame" (0xaa9f7bf0)
"make-frame-on-display" (0xaa9f8348)
"server-create-window-system-frame" (0xaa9f8b78)
"server-process-filter" (0xaa9f96b8)
(gdb)
and the usual BadPixmap error. So the bug behind all this is probably
neither scroll bar nor menu related after all. I conjecture that
deleting the last GUI frame from a TTY started server messes up
something we do not initialize properly when invoking another GUI client
from it. This conjecture is supported by the fact that when I leave a
client frame open and fire up a new terminal, I can invoke the client
from the new terminal as often as I want without any problems ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 09:15:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Then I guess this should go in etc/PROBLEMS.
That's the worst case scenario, yes.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 09:36:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 27816 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I conjecture that
> deleting the last GUI frame from a TTY started server messes up
> something we do not initialize properly when invoking another GUI client
> from it. This conjecture is supported by the fact that when I leave a
> client frame open and fire up a new terminal, I can invoke the client
> from the new terminal as often as I want without any problems ...
And I confirmed my conjecture here by using the attached patch. Please
try it. I now start thinking that the GTK bug is not a GTK bug after
all ...
martin
[frame.c.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 13:32:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 27816 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> I don't get the Xaw3dComputeTopShadowRGB in my backtrace like Martin does:
[...]
>
> Maybe you should try calling ‘x-synchronize’ first. Without that I can
> get all sorts of things like, for example,
>
> #0 x_error_quitter (display=0xe6dd60, event=0x7fffebd72bc0) at ../../src/xterm.c:9855
> #1 0x000000000054763f in x_error_handler (display=0xe6dd60, event=0x7fffebd72bc0) at ../../src/xterm.c:9828
> #2 0x00007ffa6360729a in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #3 0x00007ffa636045c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #4 0x00007ffa63604605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #5 0x00007ffa63604e95 in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6 0x00007ffa635f65ad in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #7 0x0000000000545aa4 in XTread_socket (terminal=0x1e23a38, hold_quit=0x7fffebd72e20) at ../../src/xterm.c:9055
> #8 0x0000000000585ce8 in gobble_input () at ../../src/keyboard.c:6913
> #9 0x00000000005861ff in handle_async_input () at ../../src/keyboard.c:7150
> #10 0x000000000058621b in process_pending_signals () at ../../src/keyboard.c:7164
> #11 0x000000000058625a in unblock_input_to (level=0) at ../../src/keyboard.c:7179
> #12 0x000000000058627d in unblock_input () at ../../src/keyboard.c:7198
> #13 0x000000000053fdc6 in x_scroll_bar_create (w=0x156c7d0, top=37, left=1, width=16, height=612, horizontal=false) at ../../src/xterm.c:6575
> #14 0x00000000005405f4 in XTset_vertical_scroll_bar (w=0x156c7d0, portion=145, whole=145, position=0) at ../../src/xterm.c:6746
[...]
> But with ‘x-synchronize’ I reliably get the Xaw3dComputeTopShadowRGB
> bug.
Evaluating (x-synchronize t) in the first X frame doesn't seem to have
any effect for me. My interpretation of the backtraces is that the
presence of XSync() indicates synchronous mode, and since yours lacks
that you are not actually in synchronous mode (I am somewhat out of my
depth here though, so perhaps this is nonsense).
>
> BTW could you try this with a motif build? Here this gets me the backtrace
>
> #0 x_error_quitter (display=0x101b690, event=0x7fffaa9f2a60) at ../../src/xterm.c:9855
> #1 0x0000000000547477 in x_error_handler (display=0x101b690, event=0x7fffaa9f2a60) at ../../src/xterm.c:9828
> #2 0x00007f502555429a in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #3 0x00007f50255515c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #4 0x00007f5025551605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #5 0x00007f50255521f8 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6 0x00007f5025536e79 in XGetGeometry () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #7 0x00007f502638cd41 in size_cascade (cascadebtn=cascadebtn <at> entry=0x1058230) at CascadeB.c:1851
> #8 0x00007f502638d713 in Initialize (w_req=0x7fffaa9f2ee0, w_new=0x1058230, args=<optimized out>, num_args=<optimized out>) at CascadeB.c:2448
> #9 0x00007f5025e99490 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
> #10 0x00007f5025e99e5f in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
> #11 0x00007f5025e9a2ab in _XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
> #12 0x00007f5025e9a5ce in XtCreateWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6
[...]
Attached are backtraces using lucid and motif. The -x-commandline-synch
ones are where I used --eval '(setq x-command-line-resources
"emacs.synchronous: true")', the -x-synchronize-call are where I
evaluated (x-synchronize t) after creating the first X frame (and they
end up the same as the one where I did nothing, as I mentioned above).
[bug-27816-badpixmap.tar.gz (application/x-gtar-compressed, attachment)]
[Message part 3 (text/plain, inline)]
> and the usual BadPixmap error. So the bug behind all this is probably
> neither scroll bar nor menu related after all. I conjecture that
> deleting the last GUI frame from a TTY started server messes up
> something we do not initialize properly when invoking another GUI client
> from it. This conjecture is supported by the fact that when I leave a
> client frame open and fire up a new terminal, I can invoke the client
> from the new terminal as often as I want without any problems ...
> And I confirmed my conjecture here by using the attached patch. Please
> try it. I now start thinking that the GTK bug is not a GTK bug after
> all ...
With this patch I can't produce the badpixmap error here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 06 Aug 2017 16:52:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 06 Aug 2017 11:34:35 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 27816 <at> debbugs.gnu.org
>
> And I confirmed my conjecture here by using the attached patch. Please
> try it. I now start thinking that the GTK bug is not a GTK bug after
> all ...
Looks reasonable, thanks. If this solves the problem, please push.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 30 Aug 2017 08:33:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> There is some other minor trouble (not
> really related to this bug I think): the scrollbar does not get drawn
> (the space where it should be is all white instead) when first opening
> the frame, unless I've set synchronous mode as above.
This should have been fixed now. Please have a look.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Wed, 30 Aug 2017 10:52:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 27816 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I've tried the recipe --without-toolkit-scroll-bars; [...] There is
>> some other minor trouble (not really related to this bug I think):
>> the scrollbar does not get drawn (the space where it should be is all
>> white instead) when first opening the frame, unless I've set
>> synchronous mode as above.
>
> This should have been fixed now. Please have a look.
I can confirm it's fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Fri, 01 Sep 2017 22:36:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 27816 <at> debbugs.gnu.org (full text, mbox):
I have pulled right now, compiled, and bug is
again there.
My configuration
./configure --prefix /package/text/emacs-26.0.50 --with-mailutils --without-imagemagick --without-pop --with-x-toolkit=lucid
Jean
On Sun, Aug 06, 2017 at 07:51:18PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 06 Aug 2017 11:34:35 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> > Cc: 27816 <at> debbugs.gnu.org
> >
> > And I confirmed my conjecture here by using the attached patch. Please
> > try it. I now start thinking that the GTK bug is not a GTK bug after
> > all ...
>
> Looks reasonable, thanks. If this solves the problem, please push.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 02 Sep 2017 06:32:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> I have pulled right now, compiled, and bug is
> again there.
The bug is _still_ there. The patch has not been applied yet because I
expected you to test it first.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sat, 02 Sep 2017 20:24:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 02, 2017 at 08:30:29AM +0200, martin rudalics wrote:
> > I have pulled right now, compiled, and bug is
> > again there.
>
> The bug is _still_ there. The patch has not been applied yet because I
> expected you to test it first.
>
> martin
Thank you for the reminder. I tested it 20 times,
and it seem to work.
Thank you, let me know when it is applied.
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 03 Sep 2017 10:15:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Thank you for the reminder. I tested it 20 times,
> and it seem to work.
Thanks for the information.
> Thank you, let me know when it is applied.
I pushed a fix that spares non-toolkit builds. Please try again.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 03 Sep 2017 10:15:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> Looks reasonable, thanks. If this solves the problem, please push.
Pushed. It seems that increasing the heap size might slightly diminish
the frequency of these crashes but I didn't find anything conclusive.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 03 Sep 2017 10:16:03 GMT)
Full text and
rfc822 format available.
Message #188 received at 27816 <at> debbugs.gnu.org (full text, mbox):
> As far as I can tell from the code, this only affects the current
> terminal (GUI frame). What seems to work is this:
>
> emacs -Q -nw --eval '(setq x-command-line-resources "emacs.synchronous: true")'
>
> I've tried the recipe --without-toolkit-scroll-bars; the error does not
> occur under this configuration. There is some other minor trouble (not
> really related to this bug I think): the scrollbar does not get drawn
> (the space where it should be is all white instead) when first opening
> the frame, unless I've set synchronous mode as above.
> Evaluating (x-synchronize t) in the first X frame doesn't seem to have
> any effect for me. My interpretation of the backtraces is that the
> presence of XSync() indicates synchronous mode, and since yours lacks
> that you are not actually in synchronous mode (I am somewhat out of my
> depth here though, so perhaps this is nonsense).
You're probably right here. But note that the OP of Bug#23499 did do that
under GDB as
run -Q -nw -xrm "emacs.synchronous: true" -f server-start
and did not get any XSync()s either. In either case some advice on how
to debug the client under X would useful. I'm still completely ignorant
in this department.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 03 Sep 2017 15:48:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 27816 <at> debbugs.gnu.org (full text, mbox):
On Sun, Sep 3, 2017 at 6:14 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> What seems to work is this:
>>
>> emacs -Q -nw --eval '(setq x-command-line-resources
>> "emacs.synchronous: true")'
>>
>
> You're probably right here. But note that the OP of Bug#23499 did do that
> under GDB as
>
> run -Q -nw -xrm "emacs.synchronous: true" -f server-start
>
> and did not get any XSync()s either. In either case some advice on how
> to debug the client under X would useful. I'm still completely ignorant
> in this department.
From what I could tell, the '-xrm' option is ignored when '-nw' is
used, which is why I used '--eval' instead.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Sun, 03 Sep 2017 17:32:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 27816 <at> debbugs.gnu.org (full text, mbox):
>>From what I could tell, the '-xrm' option is ignored when '-nw' is
> used, which is why I used '--eval' instead.
Sounds elementary. I nevertheless added your proposal to etc/DEBUG.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27816; Package
emacs.
(Mon, 16 Jul 2018 22:23:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 27816 <at> debbugs.gnu.org (full text, mbox):
close 27816 26.1
quit
martin rudalics <rudalics <at> gmx.at> writes:
>> Thank you for the reminder. I tested it 20 times,
>> and it seem to work.
>
> Thanks for the information.
>
>> Thank you, let me know when it is applied.
>
> I pushed a fix that spares non-toolkit builds. Please try again.
I guess we may as well close the bug then.
bug marked as fixed in version 26.1, send any further explanations to
27816 <at> debbugs.gnu.org and bugs <at> gnu.support (Jean Louis)
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 16 Jul 2018 22:23:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 14 Aug 2018 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.