Problems running gdb in emacs on Windows 8.1

William M. (Mike) Miller
Thu Jun 18 16:01:00 GMT 2015

On Thu, Jun 18, 2015 at 10:29 AM, Ken Brown <> wrote:
> On 6/18/2015 8:09 AM, William M. (Mike) Miller wrote:
>> On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY <>
>> wrote:
>>> On 17/06/2015 15:53, William M. (Mike) Miller wrote:
>>>> I'm having numerous problems recently running gdb inside emacs (both
>>>> -w32 and -X11):
>>> [...]
>>>> All of these things used to work fine.  I'm not sure exactly when
>>>> things changed, as I didn't update my Cygwin installation for quite a
>>>> while.  My current installation has gdb 7.9.1-1 and emacs 24.5-1.
>>>> Any thoughts on what the problem might be and how to fix it would be
>>>> appreciated.
>>> gdb 7.9.1-1 is supposed to be marked as a test release, so I am not sure
>>> how
>>> you come to be running it without explicitly asking for it.
>>> In any case, you might try downgrading to gdb 7.8-2 to see if that
>>> changes
>>> anything.
>> Thanks for the reply.  Unfortunately, I was having the same problems
>> with gdb 7.8-2 and installed the latest to see if it helped.  It
>> didn't.
> Can you give a detailed recipe for reproducing the problem (preferably
> starting from 'emacs -Q' and using gdb 7.8-2)?

Here's what I did, after reinstalling gdb 7.8-2.  ("emacs" is "emacs-X11".)

1) emacs -Q somefile.c&
2) M-x eval-expression (setq gdb-many-windows t)
3) M-x eval-expression (setq gdb-show-threads-by-default t)
4) M-x gdb
5) I edited the path of the executable so that it named a symlink to
the executable in the directory in which I wanted to run the program
6) In the *gud-xxx.exe* window: b foo
7) In the *gud-xxx.exe* window: run <cmd-line-arguments>

The breakpoint was hit and the source window updated to the breakpoint
location; however, all the other windows (locals, stack frames,
threads) were empty.

8) In the *gud-xxx.exe* window: up

At this point, the source window (middle-left) is still showing the
breakpoint location, not the calling function; the stack frame window
has the stack trace but points to frame 0; the locals window shows the
variables for frame 0; and the threads windows shows the program
threads as "stopped".

9) In the *gud-xxx.exe* window: up

Windows shift to displaying information for frame 1.

10) In the *gud-xxx.exe* window: p 0

The source and locals windows shift to frame 2 information, but the
stack frames window still indicates frame 1.

11) In the *gud-xxx.exe* window: p 0

Now the stack frames window updates to point to frame 2.

12) In the *gud-xxx.exe* window: fr 0

The source window updates to show the breakpoint location again, but
the locals and stack frames windows still reflect frame 2.

13) In the *gud-xxx.exe* window: n

Locals and stack frames windows update to frame 0.  Source window is
correctly indicating execution point.

14) In the *gud-xxx.exe* window: p db_foo(x)

Output from debugging function db_foo (to stderr) appears in the
input/output window correctly, but all threads in the thread window
now indicate "running" instead of "stopped".  All other windows
unchanged; in particular, the source window still shows the execution
point where it was.

15) In the *gud-xxx.exe* window: n

Bell rings, no changes to any window.  At this point I have to "run"
again to get back to the breakpoint.

I'm not able to reliably reproduce the replacement of the
*gud-xxx.exe* window with a source window; as I said originally, it
seems unpredictable when it will happen.

William M. (Mike) Miller | Edison Design Group

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list