X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; q=dns; s=default; b=Ab j4Oe5XfvVeR6th5Yin7GE+NUBT7E8187lt5/k3YrOu+O0ba4ReI9dOOw+jpziGxT RYiyfd3odr9H7ufUc95t8PgVvoGYH2MdkYY4EZEQNqDoOIJ/Vnl4xZSsgPHgtd4/ avNUdL0N2qZSWshZdmSZXJJxYgHR1crUXmLamP7w4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; s=default; bh=vrYSUclk YNKCgwtz0aDfyXUpa70=; b=ttuIw9FnuYrDKoY3T15TzCho9MqkjzvotfZg7D2s OFd6nMOUJwCdSEANy1DbRNaO1qgtL1nXM8qQVJRQoyQI5G4kqGoK/pDHneHOn2yk tWDlxyHQGYLXkf1VEIAn9QEBn9X+gORJaQrlxBjScBS/itAhkLWaia7+mTeW4y/j DGg= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f169.google.com MIME-Version: 1.0 X-Received: by 10.170.218.86 with SMTP id k83mr14333435ykf.6.1434643299519; Thu, 18 Jun 2015 09:01:39 -0700 (PDT) In-Reply-To: <5582D5C4.8080500@cornell.edu> References: <5582B133 DOT 20801 AT dronecode DOT org DOT uk> <5582D5C4 DOT 8080500 AT cornell DOT edu> Date: Thu, 18 Jun 2015 12:01:39 -0400 Message-ID: Subject: Re: Problems running gdb in emacs on Windows 8.1 From: "William M. (Mike) Miller" To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes 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 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 DOT m DOT miller AT gmail DOT 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