On Thu, Jun 18, 2015 at 10:29 AM, Ken Brown <kbr...@cornell.edu> wrote:
> On 6/18/2015 8:09 AM, William M. (Mike) Miller wrote:
>>
>> On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY <jon.tur...@dronecode.org.uk>
>> 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
william.m.mil...@gmail.com
--
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
