X protocol error

X protocol error

[Colin Baxter]

On a fresh git clone of emacs and after a seemingly successful make
bootstrap I get the message

X protocol error: XI_BadDevice (invalid Device parameter) on protocol request 131
Serial no: 54

when I attempt to launch emacs. I have no idea what the message means.

Best wishes,

Colin Baxter.

Re: X protocol error

[Po Lu]

Colin Baxter <m43cap@yandex.com> writes:

> On a fresh git clone of emacs and after a seemingly successful make
> bootstrap I get the message
>
> X protocol error: XI_BadDevice (invalid Device parameter) on protocol request 131
> Serial no: 54
>
> when I attempt to launch emacs. I have no idea what the message means.
>
> Best wishes,

Please run Emacs under a debugger like this:

  (gdb) run -q -xrm "Emacs.synchronous: true"

and show the resulting backtrace once the breakpoint on the X error
handler is hit.

Thanks.

Re: X protocol error

[Colin Baxter]

Dear Po,

Thanks for your reply. I have narrowed the problem to the configure option
"./configure --with-x-toolkit=lucid <RET>". If I run only "./configure
<RET>", effectively using the gtk3 default setting then emacs builds
successfully.

>>>>> Po Lu <luangruo@yahoo.com> writes:

    > Colin Baxter <m43cap@yandex.com> writes:
    >> On a fresh git clone of emacs and after a seemingly successful
    >> make bootstrap I get the message
    >> 
    >> X protocol error: XI_BadDevice (invalid Device parameter) on
    >> protocol request 131 Serial no: 54
    >> 
    >> when I attempt to launch emacs. I have no idea what the message
    >> means.
    >> 
    >> Best wishes,

    > Please run Emacs under a debugger like this:

    >   (gdb) run -q -xrm "Emacs.synchronous: true"

    > and show the resulting backtrace once the breakpoint on the X
    > error handler is hit.

In an xterm, in my directory ~/git/emacs/src, if I launch gdb and then
enter your command. I get the following:

--8<---------------cut here---------------start------------->8---
gdb$ run -q -xrm "Emacs.synchronous: true"
Starting program:  -q -xrm "Emacs.synchronous: true"
No executable file specified.
Use the "file" or "exec-file" command.
--8<---------------cut here---------------end--------------->8---

I am obviously doing something stupid. I have not used gbd before so you
will have to talk me through the method in some detail. For instance,
must have compiled (made?) emacs using some debugger option? Sorry to
be dim.

Best wishes,

Re: X protocol error

[Robert Pluim]

>>>>> On Wed, 17 Aug 2022 15:08:03 +0100, Colin Baxter <m43cap@yandex.com> said:

    Colin> Dear Po,
    Colin> Thanks for your reply. I have narrowed the problem to the configure option
    Colin> "./configure --with-x-toolkit=lucid <RET>". If I run only "./configure
    Colin> <RET>", effectively using the gtk3 default setting then emacs builds
    Colin> successfully.

    Colin> gdb$ run -q -xrm "Emacs.synchronous: true"
    Colin> Starting program:  -q -xrm "Emacs.synchronous: true"
    Colin> No executable file specified.
    Colin> Use the "file" or "exec-file" command.

I think Po Lu meant:
    $ cd src
    $ gdb emacs
    gdb$ run -q -xrm "Emacs.synchronous: true"

I can reproduce this with a lucid build (with XI2 enabled):

Thread 1 "emacs" hit Breakpoint 2, x_error_quitter (display=0x555555f79210, 
    event=0x7fffffffc1c0) at xterm.c:24762
24762	  if (event->error_code == BadName)
(gdb) bt
#0  x_error_quitter (display=0x555555f79210, event=0x7fffffffc1c0)
    at xterm.c:24762
#1  0x00005555556e5f2c in x_error_handler
    (display=0x555555f79210, event=0x7fffffffc1c0) at xterm.c:24743
#2  0x00007ffff7992864 in _XError () at /lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007ffff798f327 in  () at /lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007ffff798f3c5 in  () at /lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff799062d in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff798be2b in XSync () at /lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff798becb in  () at /lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007ffff5b8dac1 in XISelectEvents () at /lib/x86_64-linux-gnu/libXi.so.6
#9  0x00005555556ebc0d in xi_select_hierarchy_events (dpyinfo=0x555555f8bce0)
    at xterm.c:27661
#10 0x00005555556ecbf1 in x_term_init
    (display_name=XIL(0x555555f65944), xrm_option=0x555555f0af88 "Emacs.synchronous: true", resource_name=0x555555f636f0 "emacs") at xterm.c:28299
#11 0x000055555570082e in Fx_open_connection
    (display=XIL(0x555555f65944), xrm_string=XIL(0x555555f499b4), must_succeed=XIL(0x30)) at xfns.c:7260
#12 0x00005555557e3b05 in funcall_subr
    (subr=0x555555dd7a00 <Sx_open_connection>, numargs=3, args=0x7ffff18a31d0)
    at eval.c:3056
#13 0x00005555558331e1 in exec_byte_code
    (fun=XIL(0x7ffff1ff945d), args_template=513, nargs=2, args=0x7ffff18a3348)
    at bytecode.c:809
#14 0x00005555557e3dbd in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22ec765), args_template=256, nargs=0, args=0x7ffff18a3150)
    at eval.c:3101
#15 0x00005555557e4131 in funcall_lambda
    (fun=XIL(0x7ffff22ec765), nargs=0, arg_vector=0x7ffff18a3150)
    at eval.c:3173
#16 0x00005555557e36a6 in funcall_general
    (fun=XIL(0x7ffff22ec765), numargs=0, args=0x7ffff18a3150) at eval.c:2964
#17 0x00005555557e3902 in Ffuncall (nargs=1, args=0x7ffff18a3148)
    at eval.c:3014
#18 0x00005555557e2a58 in Fapply (nargs=2, args=0x7ffff18a3148) at eval.c:2638
#19 0x00005555557e3ce9 in funcall_subr
    (subr=0x555555de0600 <Sapply>, numargs=2, args=0x7ffff18a3148)
    at eval.c:3079
#20 0x00005555558331e1 in exec_byte_code
    (fun=XIL(0x7ffff23d5bed), args_template=770, nargs=3, args=0x7ffff18a33c0)
    at bytecode.c:809
#21 0x00005555557e3dbd in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22ea715), args_template=0, nargs=0, args=0x7fffffffdb40)
    at eval.c:3101
#22 0x00005555557e4131 in funcall_lambda
    (fun=XIL(0x7ffff22ea715), nargs=0, arg_vector=0x7fffffffdb40)
    at eval.c:3173
#23 0x00005555557e3f4f in apply_lambda
    (fun=XIL(0x7ffff22ea715), args=XIL(0), count=...) at eval.c:3123
#24 0x00005555557e2651 in eval_sub (form=XIL(0x7ffff2730653)) at eval.c:2564
#25 0x00005555557e1c39 in Feval (form=XIL(0x7ffff2730653), lexical=XIL(0))
    at eval.c:2375
#26 0x0000555555720edc in top_level_2 () at keyboard.c:1141
#27 0x00005555557dfb8a in internal_condition_case
    (bfun=0x555555720eb9 <top_level_2>, handlers=XIL(0x90), hfun=0x555555720807 <cmd_error>) at eval.c:1497
#28 0x0000555555720f24 in top_level_1 (ignore=XIL(0)) at keyboard.c:1149
#29 0x00005555557df252 in internal_catch
    (tag=XIL(0xf7e0), func=0x555555720ede <top_level_1>, arg=XIL(0))
    at eval.c:1220
#30 0x0000555555720dfd in command_loop () at keyboard.c:1109
#31 0x00005555557203b2 in recursive_edit_1 () at keyboard.c:719
#32 0x000055555572055b in Frecursive_edit () at keyboard.c:802
#33 0x000055555571ca50 in main (argc=4, argv=0x7fffffffe0f8) at emacs.c:2517

Lisp Backtrace:
"x-open-connection" (0xf18a31d0)
0xf22ec760 PVEC_COMPILED
"apply" (0xf18a3148)
"window-system-initialization" (0xf18a30b8)
"command-line" (0xf18a3040)
"normal-top-level" (0xffffdb40)

Robert
-- 

Re: X protocol error

[Robert Pluim]

BTW, this is bug#57261. The following fixes it for me:

diff --git a/src/xterm.c b/src/xterm.c
index a40440e0da..a329ca59d0 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -27654,6 +27654,8 @@ xi_select_hierarchy_events (struct x_display_info *dpyinfo)
   memset (m, 0, l);
   mask.mask_len = l;
 
+  mask.deviceid = XIAllDevices;
+
   XISetMask (m, XI_PropertyEvent);
   XISetMask (m, XI_HierarchyChanged);
   XISetMask (m, XI_DeviceChanged);

Robert
-- 

Re: X protocol error

[Colin Baxter]

>>>>> Robert Pluim <rpluim@gmail.com> writes:

    > BTW, this is bug#57261. The following fixes it for me:

    > diff --git a/src/xterm.c b/src/xterm.c index
    > a40440e0da..a329ca59d0 100644 --- a/src/xterm.c +++ b/src/xterm.c
    > @@ -27654,6 +27654,8 @@ xi_select_hierarchy_events (struct
    > x_display_info *dpyinfo) memset (m, 0, l); mask.mask_len = l;
 
    > + mask.deviceid = XIAllDevices; + XISetMask (m, XI_PropertyEvent);
    > XISetMask (m, XI_HierarchyChanged); XISetMask (m,
    > XI_DeviceChanged);

I can confirm that your patch works for me too. Thank you.

Best wishes,

Re: bug#57261: 29.0.50; X protocol error: XI_BadDevice (invalid Device parameter) on protocol request 131, Re: X protocol error

[Robert Pluim]

>>>>> On Wed, 17 Aug 2022 18:28:43 +0300, Jean Louis <bugs@gnu.support> said:
    Jean> I have tried that, and now I can get `emacs -Q' to work again under X.

    Jean> I hope this will be repaired.

    Colin> I can confirm that your patch works for me too. Thank you.

    Colin> Best wishes,

It looks like the right thing, but Iʼd like Po Lu to confirm before I
push (I know very little about XInput2).

Robert
-- 

Re: X protocol error

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> BTW, this is bug#57261. The following fixes it for me:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index a40440e0da..a329ca59d0 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -27654,6 +27654,8 @@ xi_select_hierarchy_events (struct x_display_info *dpyinfo)
>    memset (m, 0, l);
>    mask.mask_len = l;
>  
> +  mask.deviceid = XIAllDevices;
> +
>    XISetMask (m, XI_PropertyEvent);
>    XISetMask (m, XI_HierarchyChanged);
>    XISetMask (m, XI_DeviceChanged);

Right, thanks... In retrospect, that was pretty obvious.

Now fixed on master.

Re: X protocol error

[Colin Baxter]

>>>>> Po Lu <luangruo@yahoo.com> writes:

    > Robert Pluim <rpluim@gmail.com> writes:
    >> BTW, this is bug#57261. The following fixes it for me:
    >> 
    >> diff --git a/src/xterm.c b/src/xterm.c index
    >> a40440e0da..a329ca59d0 100644 --- a/src/xterm.c +++ b/src/xterm.c
    >> @@ -27654,6 +27654,8 @@ xi_select_hierarchy_events (struct
    >> x_display_info *dpyinfo) memset (m, 0, l); mask.mask_len = l;
    >> 
    >> + mask.deviceid = XIAllDevices; + XISetMask (m,
    >> XI_PropertyEvent); XISetMask (m, XI_HierarchyChanged); XISetMask
    >> (m, XI_DeviceChanged);

    > Right, thanks... In retrospect, that was pretty obvious.

    > Now fixed on master.

Thank you.

bug#57261: 29.0.50; X protocol error: XI_BadDevice (invalid Device parameter) on protocol request 131

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> It looks like the right thing, but Iʼd like Po Lu to confirm before I
> push (I know very little about XInput2).

Seems like this was pushed, so I'm closing this bug report.