emacs-X11 freezes with mouse cut and paste

emacs-X11 freezes with mouse cut and paste

[Rockefeller, Harry]

CYGWIN_NT-6.1 HARRYR-PC 3.0.4(0.338/5/3) 2019-03-16 09:50 x86_64 Cygwin
GNU Emacs 26.1

How this happened.
It had happened twice before but appeared to be intermittent.
This time it happened I had copied a line from an xterm, including the [return].
Moved mouse to emacs window and using the middle mouse button attempted to paste the copied text.
It didn't paste and now emacs is frozen; not responding to keyboard or mouse.

In xterm window I entered
Gdb /usr/bin/emacs-X11.exe
Gdb told me it read the symbols.
(gdb) info source
Current source file is /usr/src/debug/emacs-26.1-1/src/emacs.c
Compilation directory is /usr/src/debug/emacs-26.1-1/src
Located in /usr/src/debug/emacs-26.1-1/src/emacs.c
Contains 2676 lines.
Source language is c.
Producer is GNU C11 7.3.0 -mtune=generic -march=x86-64 -ggdb -O2 -fopenmp -fstack-protector-strong --param ssp-buffer-size=4.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
(gdb) list
660           emacs_perror ("Write error to standard output");
661           _exit (EXIT_FAILURE);
662         }
663
664       /* Do not close stderr if addresses are being sanitized, as the
665          sanitizer might report to stderr after this function is
666          invoked.  */
667       if (!ADDRESS_SANITIZER && close_stream (stderr) != 0)
668         _exit (EXIT_FAILURE);
669     }

I am not familiar with using gdb this way.  There is no "frame", no "info local", no stack.
If there is something else I can provide please let me know.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-X11 freezes with mouse cut and paste

[Ken Brown]

On 3/27/2019 10:40 AM, Rockefeller, Harry wrote:
> CYGWIN_NT-6.1 HARRYR-PC 3.0.4(0.338/5/3) 2019-03-16 09:50 x86_64 Cygwin
> GNU Emacs 26.1
> 
> How this happened.
> It had happened twice before but appeared to be intermittent.
> This time it happened I had copied a line from an xterm, including the [return].
> Moved mouse to emacs window and using the middle mouse button attempted to paste the copied text.
> It didn't paste and now emacs is frozen; not responding to keyboard or mouse.
> 
> In xterm window I entered
> Gdb /usr/bin/emacs-X11.exe
> Gdb told me it read the symbols.
> (gdb) info source
> Current source file is /usr/src/debug/emacs-26.1-1/src/emacs.c
> Compilation directory is /usr/src/debug/emacs-26.1-1/src
> Located in /usr/src/debug/emacs-26.1-1/src/emacs.c
> Contains 2676 lines.
> Source language is c.
> Producer is GNU C11 7.3.0 -mtune=generic -march=x86-64 -ggdb -O2 -fopenmp -fstack-protector-strong --param ssp-buffer-size=4.
> Compiled with DWARF 2 debugging format.
> Does not include preprocessor macro info.
> (gdb) list
> 660           emacs_perror ("Write error to standard output");
> 661           _exit (EXIT_FAILURE);
> 662         }
> 663
> 664       /* Do not close stderr if addresses are being sanitized, as the
> 665          sanitizer might report to stderr after this function is
> 666          invoked.  */
> 667       if (!ADDRESS_SANITIZER && close_stream (stderr) != 0)
> 668         _exit (EXIT_FAILURE);
> 669     }
> 
> I am not familiar with using gdb this way.  There is no "frame", no "info local", no stack.

That's because you haven't started the program.  Use the gdb "run" command. 
Alternatively, instead of running emacs under gdb, you could just run emacs as 
you normally do and then attach gdb when emacs freezes.  ("gdb -p <PID>")  At 
that point, a backtrace of all threads would be useful.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: emacs-X11 freezes with mouse cut and paste

[Rockefeller, Harry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2863 bytes --]

>On 3/27/2019 10:40 AM, Rockefeller, Harry wrote:
>> CYGWIN_NT-6.1 HARRYR-PC 3.0.4(0.338/5/3) 2019-03-16 09:50 x86_64
>> Cygwin GNU Emacs 26.1
>> How this happened.
>> It had happened twice before but appeared to be intermittent.
>> This time it happened I had copied a line from an xterm, including the [return].
>> Moved mouse to emacs window and using the middle mouse button attempted to paste the copied text.
>> It didn't paste and now emacs is frozen; not responding to keyboard or mouse.
>> In xterm window I entered
>> Gdb /usr/bin/emacs-X11.exe
>> Gdb told me it read the symbols.
>> (gdb) info source
>> Current source file is /usr/src/debug/emacs-26.1-1/src/emacs.c
>> Compilation directory is /usr/src/debug/emacs-26.1-1/src Located in
>> /usr/src/debug/emacs-26.1-1/src/emacs.c
>> Contains 2676 lines.
>> Source language is c.
>> Producer is GNU C11 7.3.0 -mtune=generic -march=x86-64 -ggdb -O2 -fopenmp -fstack-protector-strong --param ssp-buffer-size=4.
>> Compiled with DWARF 2 debugging format.
>> Does not include preprocessor macro info.
>> (gdb) list
>> 660           emacs_perror ("Write error to standard output");
>> 661           _exit (EXIT_FAILURE);
>> 662         }
>> 663
>> 664       /* Do not close stderr if addresses are being sanitized, as the
>> 665          sanitizer might report to stderr after this function is
>> 666          invoked.  */
>> 667       if (!ADDRESS_SANITIZER && close_stream (stderr) != 0)
>> 668         _exit (EXIT_FAILURE);
>> 669     }
>>
>> I am not familiar with using gdb this way.  There is no "frame", no "info local", no stack.

>That's because you haven't started the program.  Use the gdb "run" command.
>Alternatively, instead of running emacs under gdb, you could just run emacs as you normally do and then attach gdb when emacs freezes.  >("gdb -p <PID>")  At that point, a backtrace of all threads would be useful.

>Ken

It happened again.  Attached to PID as shown above.  (gdb) list gave same result as above.
(gdb) bt
#0  0x00000000773bafb1 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000077462e08 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x00000000772659cd in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/Windows/system32/kernel32.dll
#3  0x000000007739a561 in ntdll!RtlUserThreadStart () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Does this tell me the problem is not Cygwin?  Perhaps BLODA or bad hardware, maybe bad mouse?
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: emacs-X11 freezes with mouse cut and paste

[Ken Brown]

On 4/4/2019 12:25 PM, Rockefeller, Harry wrote:
>> Alternatively, instead of running emacs under gdb, you could just run emacs as you normally do and then attach gdb when emacs freezes.  >("gdb -p <PID>")  At that point, a backtrace of all threads would be useful.

> It happened again.  Attached to PID as shown above.  (gdb) list gave same result as above.
> (gdb) bt
> #0  0x00000000773bafb1 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #1  0x0000000077462e08 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #2  0x00000000772659cd in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/Windows/system32/kernel32.dll
> #3  0x000000007739a561 in ntdll!RtlUserThreadStart () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #4  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Does this tell me the problem is not Cygwin?  Perhaps BLODA or bad hardware, maybe bad mouse?

Not yet.  When you attach gdb to a process, it creates a new thread to be used 
by gdb.  What you're seeing above is the backtrace in that thread.  You need to 
switch to the main thread before you can get a useful backtrace:

(gdb) thread 1
(gdb) bt

Or you can just get a backtrace of all threads:

(gdb) thread apply all bt

The "info threads" command might clarify what's going on.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-X11 freezes with mouse cut and paste

[Achim Gratz]

Rockefeller, Harry writes:
> It happened again.  Attached to PID as shown above.  (gdb) list gave same result as above.
> (gdb) bt
> #0  0x00000000773bafb1 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #1  0x0000000077462e08 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #2  0x00000000772659cd in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/Windows/system32/kernel32.dll
> #3  0x000000007739a561 in ntdll!RtlUserThreadStart () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> #4  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Does this tell me the problem is not Cygwin?  Perhaps BLODA or bad hardware, maybe bad mouse?

Send the Emacs process a USR2 signal (maybe twice).  Once Emacs displays
a backtrace you can use it again.  Usually even pasting with the mouse
works after that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: emacs-X11 freezes with mouse cut and paste

[Rockefeller, Harry]

>> It happened again.  Attached to PID as shown above.  (gdb) list gave same result as above.
>> (gdb) bt
>> #0  0x00000000773bafb1 in ntdll!DbgBreakPoint () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #1  0x0000000077462e08 in ntdll!DbgUiRemoteBreakin () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #2  0x00000000772659cd in KERNEL32!BaseThreadInitThunk () from
>> /cygdrive/c/Windows/system32/kernel32.dll
>> #3  0x000000007739a561 in ntdll!RtlUserThreadStart () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #4  0x0000000000000000 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> Does this tell me the problem is not Cygwin?  Perhaps BLODA or bad hardware, maybe bad mouse?

>Send the Emacs process a USR2 signal (maybe twice).  Once Emacs displays a backtrace you can use it again.  Usually even pasting with the >mouse works after that.
>Regards,
>Achim.

Kill -s USR2 <PID>
worked.  I got the backtrace and the emacs session is responding to keyboard and mouse again.  Thanks.
I also used Ken's suggestion sending "thread 1" to gdb and then "bt".  It did give much more information
but I don't know if any of it is useful.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-X11 freezes with mouse cut and paste

[Achim Gratz]

Rockefeller, Harry writes:
> I also used Ken's suggestion sending "thread 1" to gdb and then "bt".
> It did give much more information but I don't know if any of it is
> useful.

It probably is useful for Ken, that's why he was asking.  It will tell
him where things got stuck.  It looks like some missing initialization
somewhere, but since it only happens when Emacs is run on Cygwin there
must be some other influence.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: emacs-X11 freezes with mouse cut and paste

[Rockefeller, Harry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 8738 bytes --]

>>> Alternatively, instead of running emacs under gdb, you could just run emacs as you normally do and then attach gdb when emacs freezes.  >>("gdb -p <PID>")  At that point, a backtrace of all threads would be useful.

>> It happened again.  Attached to PID as shown above.  (gdb) list gave same result as above.
>> (gdb) bt
>> #0  0x00000000773bafb1 in ntdll!DbgBreakPoint () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #1  0x0000000077462e08 in ntdll!DbgUiRemoteBreakin () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #2  0x00000000772659cd in KERNEL32!BaseThreadInitThunk () from
>> /cygdrive/c/Windows/system32/kernel32.dll
>> #3  0x000000007739a561 in ntdll!RtlUserThreadStart () from
>> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>> #4  0x0000000000000000 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> Does this tell me the problem is not Cygwin?  Perhaps BLODA or bad hardware, maybe bad mouse?
>
>Not yet.  When you attach gdb to a process, it creates a new thread to be used by gdb.  What you're seeing above is the backtrace in that thread.  >You need to switch to the main thread before you can get a useful backtrace:
>
>(gdb) thread 1
>(gdb) bt
>Ken
Here it is:
(gdb) bt
#0  0x00000001004e4e57 in readable_events (flags=1) at /usr/src/debug/emacs-26.1-1/src/keyboard.c:3338
#1  0x00000001004e5a85 in get_input_pending (flags=flags@entry=1) at /usr/src/debug/emacs-26.1-1/src/keyboard.c:6824
#2  0x00000001004e5b3d in swallow_events (do_display=do_display@entry=false)
    at /usr/src/debug/emacs-26.1-1/src/keyboard.c:4264
#3  0x0000000100592e0e in wait_reading_process_output (time_limit=<optimized out>, nsecs=<optimized out>,
    read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=4305482867,
    wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
    at /usr/src/debug/emacs-26.1-1/src/process.c:5547
#4  0x00000001004c5d19 in x_get_foreign_selection (selection_symbol=<optimized out>, target_type=9360, time_stamp=0,
    frame=25790477765) at /usr/src/debug/emacs-26.1-1/src/xselect.c:1201
#5  0x0000000100551ab0 in Ffuncall (nargs=<optimized out>, args=args@entry=0xffffaef8)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2769
#6  0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294947221, maxdepth=<optimized out>,
    args_template=args_template@entry=4106, nargs=<optimized out>, nargs@entry=2, args=<optimized out>,
    args@entry=0xffffb198) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#7  0x0000000100554187 in funcall_lambda (fun=4311658037, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xffffb198)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#8  0x0000000100551a2b in Ffuncall (nargs=nargs@entry=3, args=0xffffb190) at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#9  0x0000000100553560 in Fapply (nargs=2, args=0xffffb2e0) at /usr/src/debug/emacs-26.1-1/src/eval.c:2389
#10 0x0000000100551ab0 in Ffuncall (nargs=<optimized out>, args=args@entry=0xffffb2d8)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2769
#11 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294948333, maxdepth=<optimized out>,
    args_template=args_template@entry=514, nargs=<optimized out>, nargs@entry=2, args=<optimized out>,
    args@entry=0xffffb5f0) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#12 0x0000000100554187 in funcall_lambda (fun=4311084885, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xffffb5f0)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#13 0x0000000100551a2b in Ffuncall (nargs=3, args=args@entry=0xffffb5e8) at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#14 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294949125, maxdepth=<optimized out>,
    args_template=args_template@entry=2050, nargs=<optimized out>, nargs@entry=2, args=<optimized out>,
    args@entry=0xffffb908) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#15 0x0000000100554187 in funcall_lambda (fun=4302454965, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xffffb908)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#16 0x0000000100551a2b in Ffuncall (nargs=3, args=args@entry=0xffffb900) at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#17 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294949869, maxdepth=<optimized out>,
    args_template=args_template@entry=1030, nargs=<optimized out>, nargs@entry=1, args=<optimized out>,
    args@entry=0xffffbbf0) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#18 0x0000000100554187 in funcall_lambda (fun=4302453685, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xffffbbf0)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#19 0x0000000100551a2b in Ffuncall (nargs=2, args=args@entry=0xffffbbe8) at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#20 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294950549, maxdepth=<optimized out>,
    args_template=args_template@entry=2, nargs=<optimized out>, nargs@entry=0, args=<optimized out>,
    args@entry=0xffffbe98) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#21 0x0000000100554187 in funcall_lambda (fun=4302454245, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xffffbe98)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#22 0x0000000100551a2b in Ffuncall (nargs=1, args=args@entry=0xffffbe90) at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#23 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294951421, maxdepth=<optimized out>,
    args_template=args_template@entry=1030, nargs=<optimized out>, nargs@entry=1, args=<optimized out>,
    args@entry=0xffffc200) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#24 0x0000000100554187 in funcall_lambda (fun=4302432069, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xffffc200)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#25 0x0000000100551a2b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xffffc1f8)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#26 0x000000010054e423 in Ffuncall_interactively (nargs=2, args=0xffffc1f8)
    at /usr/src/debug/emacs-26.1-1/src/callint.c:252
---Type <return> to continue, or q <return> to quit---
#27 0x0000000100551ab0 in Ffuncall (nargs=nargs@entry=10043408, args=0xffffc1f0,
    args@entry=0x100588100 <exec_byte_code+704>) at /usr/src/debug/emacs-26.1-1/src/eval.c:2769
#28 0x000000010054ed4f in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>,
    keys=<optimized out>) at /usr/src/debug/emacs-26.1-1/src/callint.c:854
#29 0x0000000100551ab0 in Ffuncall (nargs=<optimized out>, args=args@entry=0xffffc448)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2769
#30 0x0000000100588100 in exec_byte_code (bytestr=<optimized out>, vector=4294952853, maxdepth=<optimized out>,
    args_template=args_template@entry=4102, nargs=<optimized out>, nargs@entry=1, args=<optimized out>,
    args@entry=0xffffc798) at /usr/src/debug/emacs-26.1-1/src/bytecode.c:629
#31 0x0000000100554187 in funcall_lambda (fun=4302011021, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xffffc798)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2970
#32 0x0000000100551a2b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xffffc790)
    at /usr/src/debug/emacs-26.1-1/src/eval.c:2783
#33 0x0000000100551b7f in call1 (fn=fn@entry=16080, arg1=<optimized out>) at /usr/src/debug/emacs-26.1-1/src/eval.c:2620
#34 0x00000001004ed24c in command_loop_1 () at /usr/src/debug/emacs-26.1-1/src/keyboard.c:1482
#35 0x0000000100550beb in internal_condition_case (bfun=bfun@entry=0x1004ecdf0 <command_loop_1>,
    handlers=handlers@entry=20928, hfun=hfun@entry=0x1004e3ca0 <cmd_error>) at /usr/src/debug/emacs-26.1-1/src/eval.c:1332
#36 0x00000001004de414 in command_loop_2 (ignore=<optimized out>) at /usr/src/debug/emacs-26.1-1/src/keyboard.c:1110
#37 0x0000000100550b5a in internal_catch (tag=tag@entry=50496, func=func@entry=0x1004de3f0 <command_loop_2>,
    arg=arg@entry=0) at /usr/src/debug/emacs-26.1-1/src/eval.c:1097
#38 0x00000001004de3a8 in command_loop () at /usr/src/debug/emacs-26.1-1/src/keyboard.c:1089
#39 0x00000001004e387d in recursive_edit_1 () at /usr/src/debug/emacs-26.1-1/src/keyboard.c:695
#40 0x00000001004e3bd4 in Frecursive_edit () at /usr/src/debug/emacs-26.1-1/src/keyboard.c:766
#41 0x00000001005e20d1 in main (argc=<optimized out>, argv=0xffffcc70) at /usr/src/debug/emacs-26.1-1/src/emacs.c:1717

\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB