RE: emacs-X11 freezes with mouse cut and paste

["Rockefeller, Harry" <Harry.Rockefeller@flightsafety.com>]

[-- 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РÐ