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
