GNU bug report logs -
#22932
25.0.92; X protocol error: BadRequest (invalid request code or no such operation) on protocol request 149
Previous Next
Reported by: John Eismeier <john.eismeier <at> emc.com>
Date: Mon, 7 Mar 2016 15:00:02 UTC
Severity: normal
Tags: moreinfo
Found in version 25.0.92
Done: Eli Zaretskii <eliz <at> gnu.org>
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 22932 in the body.
You can then email your comments to 22932 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#22932; Package
emacs.
(Mon, 07 Mar 2016 15:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
John Eismeier <john.eismeier <at> emc.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 07 Mar 2016 15:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I am using Ubuntu 14.04 with regular builds of the pretest. Moving the
window has commonly crashed emacs. How do I provide further details of
this concern?
In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2016-03-04 built on eismej-u14
Repository revision: 620951fe22a6ecc2edc1f78d961f52566a7fe2b6
Windowing system distributor 'The X.Org Foundation', version 11.0.70000000
System Description: Ubuntu 14.04.4 LTS
Configured using:
'configure --prefix=/jenkins/emacs-25/build --with-x-toolkit=lucid
--with-sound=no'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK GPM DBUS GCONF GSETTINGS
NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Info
Minor modes in effect:
tooltip-mode: t
global-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
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Sending email
Sending email done
Sending...done
Quit
You can run the command ‘info’ with C-h i
Mark set
Mark saved where search started
View mode: type C-h for help, h for commands, q to quit.
Mark set
Mark saved where search started
Load-path shadows:
None found.
Features:
(shadow emacsbug goto-addr thingatpt noutline outline easy-mmode view
epa-file epa derived network-stream nsm starttls tls gnutls mailalias
smtpmail auth-source cl-seq eieio byte-opt bytecomp byte-compile
cl-extra cconv eieio-core cl-macs gv password-cache sendmail mail-extr
sort message dired format-spec rfc822 mml mml-sec epg epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode cl-loaddefs pcase cl-lib
mail-prsvr mailabbrev mail-utils gmm-utils mailheader jka-compr
character-fold misearch multi-isearch info easymenu time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev 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 dbusbind inotify dynamic-setting
system-font-setting font-render-setting x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 140696 16786)
(symbols 48 22183 0)
(miscs 40 122 463)
(strings 32 34431 6489)
(string-bytes 1 790224)
(vectors 16 16075)
(vector-slots 8 526783 9879)
(floats 8 208 344)
(intervals 56 5321 14)
(buffers 976 21)
(heap 1024 44129 1056))
Are people seeing:
/jenkins/emacs-25/build/bin/emacs -q
X protocol error: BadRequest (invalid request code or no such operation) on protocol request 149
Fatal error 6: Aborted
Backtrace:
/jenkins/emacs-25/build/bin/emacs[0x4fb2a2]
/jenkins/emacs-25/build/bin/emacs[0x4e2d19]
/jenkins/emacs-25/build/bin/emacs[0x4fb333]
/jenkins/emacs-25/build/bin/emacs[0x450ada]
/jenkins/emacs-25/build/bin/emacs[0x450d10]
/jenkins/emacs-25/build/bin/emacs[0x54d87c]
/jenkins/emacs-25/build/bin/emacs[0x55404a]
/jenkins/emacs-25/build/bin/emacs[0x587715]
/jenkins/emacs-25/build/bin/emacs[0x553b92]
/jenkins/emacs-25/build/bin/emacs[0x553f53]
/jenkins/emacs-25/build/bin/emacs[0x587715]
/jenkins/emacs-25/build/bin/emacs[0x553b92]
/jenkins/emacs-25/build/bin/emacs[0x553f53]
/jenkins/emacs-25/build/bin/emacs[0x55248b]
/jenkins/emacs-25/build/bin/emacs[0x55404a]
/jenkins/emacs-25/build/bin/emacs[0x587715]
/jenkins/emacs-25/build/bin/emacs[0x553b92]
/jenkins/emacs-25/build/bin/emacs[0x553f53]
/jenkins/emacs-25/build/bin/emacs[0x555480]
/jenkins/emacs-25/build/bin/emacs[0x55404a]
/jenkins/emacs-25/build/bin/emacs[0x587715]
/jenkins/emacs-25/build/bin/emacs[0x553b92]
/jenkins/emacs-25/build/bin/emacs[0x553f53]
/jenkins/emacs-25/build/bin/emacs[0x55423a]
/jenkins/emacs-25/build/bin/emacs[0x4e8495]
/jenkins/emacs-25/build/bin/emacs[0x4e8799]
/jenkins/emacs-25/build/bin/emacs[0x4e9be8]
/jenkins/emacs-25/build/bin/emacs[0x4ec2b4]
/jenkins/emacs-25/build/bin/emacs[0x592632]
/jenkins/emacs-25/build/bin/emacs[0x41dcb2]
/jenkins/emacs-25/build/bin/emacs[0x4ee66b]
/jenkins/emacs-25/build/bin/emacs[0x4ef2ff]
/jenkins/emacs-25/build/bin/emacs[0x4f0d86]
/jenkins/emacs-25/build/bin/emacs[0x5529ed]
/jenkins/emacs-25/build/bin/emacs[0x4e32ac]
/jenkins/emacs-25/build/bin/emacs[0x55299b]
/jenkins/emacs-25/build/bin/emacs[0x4e3267]
/jenkins/emacs-25/build/bin/emacs[0x4e77b8]
/jenkins/emacs-25/build/bin/emacs[0x4e7ad5]
/jenkins/emacs-25/build/bin/emacs[0x413bd3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f7b2b7beec5]
...
Aborted (core dumped)
I don't see a core file to help with a backtrace.
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Mon, 07 Mar 2016 16:22:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22932 <at> debbugs.gnu.org (full text, mbox):
> From: John Eismeier <john.eismeier <at> emc.com>
> Date: Mon, 07 Mar 2016 08:41:23 -0500
>
>
> I am using Ubuntu 14.04 with regular builds of the pretest. Moving the
> window has commonly crashed emacs. How do I provide further details of
> this concern?
The file etc/DEBUG provides advice for this case (search for "X
protocol errors"). Do what it says to put Emacs into the synchronous
X mode, after starting Emacs under GDB and setting a breakpoint at
x_error_quitter. Then show the backtrace you obtain.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 13:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Thank you Eli,
I am part way there, is this enough of a backtrace? How do I configure
gdb to use the -Q argument when running under gdb
/jenkins/emacs-25/build/bin/emacs -Q
Warning: Missing charsets in String to FontSet conversion
X protocol error: BadRequest (invalid request code or no such operation) on protocol request 149
Fatal error 6: Aborted
Backtrace:
/jenkins/emacs-25/build/bin/emacs[0x4fb362]
/jenkins/emacs-25/build/bin/emacs[0x4e2dd9]
/jenkins/emacs-25/build/bin/emacs[0x4fb3f3]
/jenkins/emacs-25/build/bin/emacs[0x450ada]
/jenkins/emacs-25/build/bin/emacs[0x450d10]
/jenkins/emacs-25/build/bin/emacs[0x54d94c]
/jenkins/emacs-25/build/bin/emacs[0x55411a]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x553c62]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x553c62]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x554279]
/jenkins/emacs-25/build/bin/emacs[0x55255b]
/jenkins/emacs-25/build/bin/emacs[0x552ce7]
/jenkins/emacs-25/build/bin/emacs[0x4e2d09]
/jenkins/emacs-25/build/bin/emacs[0x4b9b6d]
/jenkins/emacs-25/build/bin/emacs[0x4bd70e]
/jenkins/emacs-25/build/bin/emacs[0x4bd785]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x12b)[0x7f31c620654b]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3b5e7)[0x7f31c62035e7]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x2f7)[0x7f31c6204687]
/usr/lib/x86_64-linux-gnu/libXrandr.so.2(+0x56f9)[0x7f31c3b5b6f9]
/jenkins/emacs-25/build/bin/emacs[0x4cb4ce]
/jenkins/emacs-25/build/bin/emacs[0x4cbaad]
/jenkins/emacs-25/build/bin/emacs[0x4cdd52]
/jenkins/emacs-25/build/bin/emacs[0x5541ae]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x553c62]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
/jenkins/emacs-25/build/bin/emacs[0x553c62]
/jenkins/emacs-25/build/bin/emacs[0x554023]
/jenkins/emacs-25/build/bin/emacs[0x55255b]
/jenkins/emacs-25/build/bin/emacs[0x55411a]
/jenkins/emacs-25/build/bin/emacs[0x5877e5]
...
Aborted (core dumped)
eismej <at> eismej-u14:/jenkins/emacs-25/emacs$
Eli Zaretskii writes:
>> From: John Eismeier <john.eismeier <at> emc.com>
>> Date: Mon, 07 Mar 2016 08:41:23 -0500
>>
>>
>> I am using Ubuntu 14.04 with regular builds of the pretest. Moving the
>> window has commonly crashed emacs. How do I provide further details of
>> this concern?
>
> The file etc/DEBUG provides advice for this case (search for "X
> protocol errors"). Do what it says to put Emacs into the synchronous
> X mode, after starting Emacs under GDB and setting a breakpoint at
> x_error_quitter. Then show the backtrace you obtain.
>
> Thanks.
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 14:37:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 22932 <at> debbugs.gnu.org (full text, mbox):
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?
/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 ?
(gdb)
(gdb) c
Continuing.
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
#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
#43 0x0000000000641c91 in Ffuncall (nargs=7, args=0x7fffa51e6048)
at eval.c:2714
#44 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#45 0x00000000006429ab in funcall_lambda (fun=..., nargs=2,
arg_vector=0xb89f6d <pure+1849229>) at eval.c:2921
#46 0x0000000000641db8 in Ffuncall (nargs=3, args=0x7fffa51e67d8)
at eval.c:2742
#47 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#48 0x00000000006429ab in funcall_lambda (fun=..., nargs=1,
arg_vector=0xb8a7a5 <pure+1851333>) at eval.c:2921
#49 0x0000000000641db8 in Ffuncall (nargs=2, args=0x7fffa51e70c0)
at eval.c:2742
#50 0x000000000064130c in run_hook_with_args (nargs=2, args=0x7fffa51e70c0,
funcall=0x641708 <Ffuncall>) at eval.c:2509
#51 0x0000000000640ebd in Frun_hook_with_args_until_success (nargs=2,
args=0x7fffa51e70c0) at eval.c:2395
#52 0x00000000006419ec in Ffuncall (nargs=3, args=0x7fffa51e70b8)
at eval.c:2673
#53 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#54 0x00000000006429ab in funcall_lambda (fun=..., nargs=1,
arg_vector=0xb89c9d <pure+1848509>) at eval.c:2921
#55 0x0000000000641db8 in Ffuncall (nargs=2, args=0x7fffa51e79a0)
at eval.c:2742
#56 0x00000000006407f0 in Fapply (nargs=2, args=0x7fffa51e79a0) at eval.c:2278
#57 0x00000000006419ec in Ffuncall (nargs=3, args=0x7fffa51e7998)
at eval.c:2673
#58 0x000000000068fc5c in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#59 0x00000000006429ab in funcall_lambda (fun=..., nargs=1,
arg_vector=0xb1ac95 <pure+1393845>) at eval.c:2921
#60 0x0000000000641db8 in Ffuncall (nargs=2, args=0x7fffa51e8140)
at eval.c:2742
#61 0x0000000000641489 in call1 (fn=..., arg1=...) at eval.c:2552
#62 0x000000000059610b in timer_check_2 (timers=..., idle_timers=...)
at keyboard.c:4420
#63 0x000000000059623f in timer_check () at keyboard.c:4482
#64 0x00000000005939e1 in readable_events (flags=1) at keyboard.c:3321
#65 0x000000000059bbcc in get_input_pending (flags=1) at keyboard.c:6718
#66 0x00000000005a39a7 in detect_input_pending_run_timers (do_display=true)
at keyboard.c:9853
#67 0x000000000069f6f3 in wait_reading_process_output (time_limit=90, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:4963
#68 0x00000000004232f0 in sit_for (timeout=..., reading=true, display_option=1)
at dispnew.c:5762
#69 0x00000000005918a1 in read_char (commandflag=1, map=..., prev_event=...,
used_mouse_menu=0x7fffa51e8ac5, end_time=0x0) at keyboard.c:2707
#70 0x00000000005a1b6c in read_key_sequence (keybuf=0x7fffa51e8cf0,
bufsize=30, prompt=..., dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9054
#71 0x000000000058da12 in command_loop_1 () at keyboard.c:1358
#72 0x000000000063ddc8 in internal_condition_case (
bfun=0x58d5ca <command_loop_1>, handlers=..., hfun=0x58cc16 <cmd_error>)
at eval.c:1309
#73 0x000000000058d1f8 in command_loop_2 (ignore=...) at keyboard.c:1100
#74 0x000000000063d336 in internal_catch (tag=...,
func=0x58d1cf <command_loop_2>, arg=...) at eval.c:1074
#75 0x000000000058d198 in command_loop () at keyboard.c:1079
#76 0x000000000058c70d in recursive_edit_1 () at keyboard.c:685
#77 0x000000000058c909 in Frecursive_edit () at keyboard.c:756
#78 0x000000000058a578 in main (argc=4, argv=0x7fffa51e90e8) at emacs.c:1605
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 16:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 22932 <at> debbugs.gnu.org (full text, mbox):
> From: John Eismeier <john.eismeier <at> emc.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 22932 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 20:02:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 22932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:
> > From: John Eismeier <john.eismeier <at> emc.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 22932 <at> 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?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 20:11:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Ken,
I am running Ubuntu 14.04 LTS.
xrandr -v
xrandr program version 1.4.1
Server reports RandR version 1.2
What should I do next ? I still need to run this revision of the OS
with our current product development strategy.
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 20:34:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 22932 <at> debbugs.gnu.org (full text, mbox):
> From: John Eismeier <john.eismeier <at> emc.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, john.eismeier <at> emc.com, 22932 <at> debbugs.gnu.org
> Date: Tue, 08 Mar 2016 15:10:09 -0500
>
> I am running Ubuntu 14.04 LTS.
>
>
> xrandr -v
> xrandr program version 1.4.1
> Server reports RandR version 1.2
>
> What should I do next ? I still need to run this revision of the OS
> with our current product development strategy.
I guess this means Ken was right, and we should check the server
version before issuing the call. I hope Ken will be able to propose a
patch along those lines.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 20:44:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 22932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 8, 2016 at 3:10 PM, John Eismeier <john.eismeier <at> emc.com> wrote:
>
> Ken,
>
> I am running Ubuntu 14.04 LTS.
>
>
> xrandr -v
> xrandr program version 1.4.1
> Server reports RandR version 1.2
>
How odd! I'm running Ubuntu 12.04 LTS at work and its X server reports
support for 1.3.
>
> What should I do next ? I still need to run this revision of the OS
> with our current product development strategy.
>
Well, I think I see where the issue is. The code as written -- at least in
that function -- assumes that if your libraries have the newer function,
then your server supports it. That doesn't seem to be the case here.
In reading up on this today, I've already run across a few web pages
showing which RandR requests were added in 1.3 and how to test the protocol
version supported by the server. If you want to dig into X11 programming
you're welcome to help out :-), otherwise I'll try to make some time this
evening to look into coding the run-time protocol version checks.
In the meantime, if you want something that just runs without crashing this
way, you could disable the use of the XRANDR extension. The configure
script isn't set up to make that easy from the command line, but you could
edit the config files generated. After running configure, look in
src/config.h for the line:
#define HAVE_XRANDR 1
... and comment it out. Then finish building Emacs normally. From a quick
test on my system that seems to work okay, though I don't know off the top
of my head what functionality might be diminished by losing the xrandr
support.
Ken
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 20:49:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 22932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
By the way, John, I'm curious: Could you please run "xdpyinfo" and send the
first dozen lines or so of output? I'd like to see what server is running
and how it identifies itself...
Ken
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 22:06:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Sure Ken, How did I end of with old xrandr ?
dpkg -l |grep xrandr
ii libnx-xrandr2:a 2:3.5.0.32-0 amd64 nx-X11 RandR extension library
ii libxrandr-dev:a 2:1.4.2-1 amd64 X11 RandR extension library (develop
ii libxrandr2:amd6 2:1.4.2-1 amd64 X11 RandR extension library
that is why, using X2go server...
xdpyinfo
name of display: :50
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 70000000
X.Org version: 7.0.0
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 22:17:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 22932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ah, that makes sense, if you've got such an old server version. We
certainly shouldn't be assuming the server is as new as the client
libraries... I'll see if I can fix that tonight.
Ken
On Tue, Mar 8, 2016 at 5:04 PM, John Eismeier <john.eismeier <at> emc.com> wrote:
>
> Sure Ken, How did I end of with old xrandr ?
>
> dpkg -l |grep xrandr
> ii libnx-xrandr2:a 2:3.5.0.32-0 amd64 nx-X11 RandR extension
> library
> ii libxrandr-dev:a 2:1.4.2-1 amd64 X11 RandR extension library
> (develop
> ii libxrandr2:amd6 2:1.4.2-1 amd64 X11 RandR extension library
>
> that is why, using X2go server...
>
> xdpyinfo
> name of display: :50
> version number: 11.0
> vendor string: The X.Org Foundation
> vendor release number: 70000000
> X.Org version: 7.0.0
> maximum request size: 16777212 bytes
> motion buffer size: 256
> bitmap unit, bit order, padding: 32, LSBFirst, 32
> image byte order: LSBFirst
> number of supported pixmap formats: 7
> supported pixmap formats:
>
>
> --
> -- John
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Tue, 08 Mar 2016 22:40:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Thanks Ken and Eli !!!
I will pull for updates tomorrow...
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Wed, 09 Mar 2016 03:44:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 22932 <at> debbugs.gnu.org (full text, mbox):
I think I’ve got a change that’ll fix it for you, John, but with only XRANDR 1.3 displays I can’t really test it.
Please check out the branch “scratch/raeburn/xrandr” and try it out. If that works for you, I can merge it to emacs-25.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Wed, 09 Mar 2016 13:17:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Nice Ken,
I have checked out the branch, run make distclean, and configure as shown
below. I will start running the newly built emacs and report back to
you with my findings.
git status
On branch scratch/raeburn/xrandr
Your branch is up-to-date with 'origin/scratch/raeburn/xrandr'.
nothing to commit, working directory clean
./configure --prefix=/jenkins/emacs-25/build --with-x-toolkit=lucid --with-sound=no
Thanks.
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Thu, 10 Mar 2016 09:44:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Ken,
emacs-25 is still running !!!
Thank you.
--
-- John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Thu, 10 Mar 2016 20:20:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 22932 <at> debbugs.gnu.org (full text, mbox):
> emacs-25 is still running !!!
Excellent, thanks for testing it. I’ve pushed the change to the emacs-25 branch.
Ken
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Thu, 10 Mar 2016 20:34:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
John Eismeier <john.eismeier <at> emc.com>:
bug acknowledged by developer.
(Thu, 10 Mar 2016 20:34:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 22932-done <at> debbugs.gnu.org (full text, mbox):
> From: Ken Raeburn <raeburn <at> permabit.com>
> Date: Thu, 10 Mar 2016 15:19:07 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 22932 <at> debbugs.gnu.org
>
> > emacs-25 is still running !!!
>
> Excellent, thanks for testing it. I’ve pushed the change to the emacs-25 branch.
Thanks, closing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22932; Package
emacs.
(Thu, 10 Mar 2016 20:42:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 22932 <at> debbugs.gnu.org (full text, mbox):
Great Ken!
I am switching back to branch emacs-25 and rebuilding with the current updates.
--
-- John
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 08 Apr 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 125 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.