This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: emacs-X11 freezes with mouse cut and paste
- From: "Rockefeller, Harry" <Harry dot Rockefeller at flightsafety dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Thu, 4 Apr 2019 16:25:19 +0000
- Subject: RE: emacs-X11 freezes with mouse cut and paste
- References: <fa6ec2233a744738b4efa74af9e9e68c@vsrv060ex01.ssd.fsi.com> <614fbba4-3425-4705-3342-99bbe8684ee0@cornell.edu>
>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?