From: Ken Raeburn <raeburn@permabit.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22932@debbugs.gnu.org, john.eismeier@emc.com
Subject: bug#22932: 25.0.92; X protocol error: BadRequest (invalid request code or no such operation) on protocol request 149
Date: Tue, 8 Mar 2016 15:01:24 -0500 [thread overview]
Message-ID: <CAJJWxE8jZ34o1-pOzRdrVgrj_n+bT9-jakQ3xxWvWV3fehVaGw@mail.gmail.com> (raw)
In-Reply-To: <8337s1rl3a.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 6511 bytes --]
In sync mode, there isn't a lot going on that the error could be caused by.
By any chance could there have been an old display server in use that
doesn't support all the modern RandR extensions?
John, could you try "xrandr -v" against the same display where you were
running Emacs? If it says the server supports version 1.3, then the
RRGetScreenResourcesCurrent request (the one in use at xfns.c:4266) should
be supported, as I understand it.
If there are servers out there still supporting only 1.2, then we may need
to check the server version before issuing that request.
Ken
On Tue, Mar 8, 2016 at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: John Eismeier <john.eismeier@emc.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 22932@debbugs.gnu.org
> > Date: Tue, 08 Mar 2016 09:36:13 -0500
> >
> >
> > I have recompiled with the arguments below, what this correct?
> >
> > CFLAGS='-O0 -g3' ./configure --prefix=/jenkins/emacs-25/build
> --with-x-toolkit=lucid --with-sound=no --enable-checking='yes,glyphs'
> --enable-check-lisp-object-type
> >
> > launched with, was this correct?
>
> Yes, thanks.
>
> > /jenkins/emacs-25/build/bin/emacs -Q -xrm "emacs.synchronous: true"
> > X protocol error: BadRequest (invalid request code or no such operation)
> on protocol request 149
> > Fatal error 6: Aborted
> >
> >
> > does this help ?
>
> It does.
>
> > Program received signal SIGABRT, Aborted.
> > 0x00007f7fea31820b in raise (sig=6)
> > at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
> > 37 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or
> directory.
> > (gdb)
> > #0 0x00007f7fea31820b in raise (sig=6)
> > at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
> > #1 0x0000000000588c38 in terminate_due_to_signal (sig=6,
> backtrace_limit=40)
> > at emacs.c:380
> > #2 0x00000000005b5efc in emacs_abort () at sysdep.c:2247
> > #3 0x000000000046833f in redisplay_internal () at xdisp.c:13458
> > #4 0x000000000046aad6 in redisplay_preserve_echo_area (from_where=13)
> > at xdisp.c:14250
> > #5 0x0000000000695009 in Fdelete_process (process=...) at process.c:841
> > #6 0x00000000006a41de in kill_buffer_processes (buffer=...) at
> process.c:7231
> > #7 0x000000000058af10 in shut_down_emacs (sig=6, stuff=...) at
> emacs.c:1978
> > #8 0x0000000000588be8 in terminate_due_to_signal (sig=6,
> backtrace_limit=40)
> > at emacs.c:364
> > #9 0x00000000005b5efc in emacs_abort () at sysdep.c:2247
> > #10 0x000000000045f65c in message3_nolog (m=...) at xdisp.c:10280
> > #11 0x000000000045f46d in message3 (m=...) at xdisp.c:10240
> > #12 0x00000000006329af in Fmessage (nargs=2, args=0x7fffa51e3680)
> > at editfns.c:3686
> > #13 0x00000000006419ec in Ffuncall (nargs=3, args=0x7fffa51e3678)
> > at eval.c:2673
> > #14 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
> > maxdepth=..., args_template=..., nargs=0, args=0x7fffa51e3e00)
> > at bytecode.c:880
> > #15 0x000000000064253a in funcall_lambda (fun=..., nargs=0,
> > arg_vector=0x7fffa51e3e00) at eval.c:2855
> > #16 0x0000000000641db8 in Ffuncall (nargs=1, args=0x7fffa51e3df8)
> > at eval.c:2742
> > #17 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
> > maxdepth=..., args_template=..., nargs=2, args=0x7fffa51e4590)
> > at bytecode.c:880
> > #18 0x000000000064253a in funcall_lambda (fun=..., nargs=2,
> > arg_vector=0x7fffa51e4580) at eval.c:2855
> > #19 0x0000000000641db8 in Ffuncall (nargs=3, args=0x7fffa51e4578)
> > at eval.c:2742
> > #20 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
> > maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
> > #21 0x00000000006429ab in funcall_lambda (fun=..., nargs=0,
> > arg_vector=0x32a78dd) at eval.c:2921
> > #22 0x0000000000641db8 in Ffuncall (nargs=1, args=0x7fffa51e4ce8)
> > at eval.c:2742
> > #23 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
> > maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
> > #24 0x00000000006429ab in funcall_lambda (fun=..., nargs=0,
> > arg_vector=0x32a2bbd) at eval.c:2921
> > #25 0x0000000000641db8 in Ffuncall (nargs=1, args=0x7fffa51e5500)
> > at eval.c:2742
> > #26 0x0000000000640e0f in funcall_nil (nargs=1, args=0x7fffa51e5500)
> > at eval.c:2332
> > #27 0x000000000064130c in run_hook_with_args (nargs=1,
> args=0x7fffa51e5500,
> > funcall=0x640dec <funcall_nil>) at eval.c:2509
> > #28 0x0000000000640e93 in Frun_hook_with_args (nargs=1,
> args=0x7fffa51e5500)
> > at eval.c:2374
> > #29 0x0000000000641399 in run_hook (hook=...) at eval.c:2522
> > #30 0x000000000058ad41 in Fkill_emacs (arg=...) at emacs.c:1898
>
> This Emacs was killed 4 times over, oh boy...
>
> > #31 0x0000000000557d31 in x_connection_closed (dpy=0xe6d880,
> > error_message=0x7fffa51e5760 "X protocol error: BadRequest (invalid
> request code or no such operation) on protocol request 149", ioerror=false)
> > at xterm.c:9484
> > #32 0x0000000000557e67 in x_error_quitter (display=0xe6d880,
> > event=0x7fffa51e5910) at xterm.c:9553
> > #33 0x0000000000557db4 in x_error_handler (display=0xe6d880,
> > event=0x7fffa51e5910) at xterm.c:9523
> > #34 0x00007f7fee9a854b in _XError () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> > #35 0x00007f7fee9a55e7 in ?? () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> > #36 0x00007f7fee9a6687 in _XReply () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> > #37 0x00007f7fec2fd6f9 in ?? () from
> /usr/lib/x86_64-linux-gnu/libXrandr.so.2
> > #38 0x0000000000568c78 in x_get_monitor_attributes_xrandr
> (dpyinfo=0xe79020)
> > at xfns.c:4266
> > #39 0x000000000056905e in x_get_monitor_attributes (dpyinfo=0xe79020)
> > at xfns.c:4369
> > #40 0x0000000000569127 in Fx_display_monitor_attributes_list
> (terminal=...)
> > at xfns.c:4515
> > #41 0x000000000056c65f in compute_tip_xy (f=0x61b5260, parms=..., dx=...,
> > dy=..., width=463, height=22, root_x=0x7fffa51e5e80,
> root_y=0x7fffa51e5e84)
> > at xfns.c:5707
> > #42 0x000000000056da31 in Fx_show_tip (string=..., frame=..., parms=...,
> > timeout=..., dx=..., dy=...) at xfns.c:6055
>
> OK, the error happens when Emacs attempts to display a tooltip. Is it
> correct that you cannot show a tooltip at all without crashing Emacs?
>
> As to why, we need help from X experts. The immediate reason is the
> call to x_get_monitor_attributes_xrandr. Ken, can you take a look?
> Why would that call trigger an X error?
>
[-- Attachment #2: Type: text/html, Size: 7794 bytes --]
next prev parent reply other threads:[~2016-03-08 20:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 13:41 bug#22932: 25.0.92; X protocol error: BadRequest (invalid request code or no such operation) on protocol request 149 John Eismeier
2016-03-07 16:21 ` Eli Zaretskii
2016-03-08 13:04 ` John Eismeier
2016-03-08 14:36 ` John Eismeier
2016-03-08 16:27 ` Eli Zaretskii
2016-03-08 20:01 ` Ken Raeburn [this message]
2016-03-08 20:10 ` John Eismeier
2016-03-08 20:33 ` Eli Zaretskii
2016-03-08 20:43 ` Ken Raeburn
2016-03-08 20:47 ` Ken Raeburn
2016-03-08 22:04 ` John Eismeier
2016-03-08 22:16 ` Ken Raeburn
2016-03-08 22:39 ` John Eismeier
2016-03-09 3:42 ` Ken Raeburn
2016-03-09 13:15 ` John Eismeier
2016-03-10 9:42 ` John Eismeier
2016-03-10 20:19 ` Ken Raeburn
2016-03-10 20:33 ` Eli Zaretskii
2016-03-10 20:41 ` John Eismeier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJJWxE8jZ34o1-pOzRdrVgrj_n+bT9-jakQ3xxWvWV3fehVaGw@mail.gmail.com \
--to=raeburn@permabit.com \
--cc=22932@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=john.eismeier@emc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).