X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,MAY_BE_FORGED,RCVD_IN_HOSTKARMA_NO,SPF_NEUTRAL,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4FA42BDA.7060204@cornell.edu>
Date: Fri, 04 May 2012 15:19:54 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gdb problem
References: <4EA329A3 DOT 30800 AT cornell DOT edu> <20111023190414 DOT GB13536 AT ednor DOT casa DOT cgf DOT cx> <4EA48B80 DOT 2080205 AT cornell DOT edu> <4FA2E4F0 DOT 1000704 AT cornell DOT edu> <20120504031001 DOT GA30260 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20120504031001.GA30260@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-CORNELL-SPAM-CHECKED: Pawpaw
X-Original-Sender: kbrown AT cornell DOT edu - Fri May  4 15:19:53 2012
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 5/3/2012 11:10 PM, Christopher Faylor wrote:
> On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:
>> On 10/23/2011 5:47 PM, Ken Brown wrote:
>>> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>>>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>>>>> The attached testcase illustrates a problem with `gdb -i=mi'. I've
>>>>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
>>>>> several recent snapshots (including 2011-10-22).
>>>>>
>>>>> Under some circumstances, if gdb -i=mi is started and given several
>>>>> input lines at once, it only prints part of the output before stopping.
>>>>> I've been able to reproduce this once in a while while working
>>>>> interactively (by copying and pasting the whole bunch of input lines);
>>>>> in this case one can press Return to get the rest of the output. But
>>>>> the problem happens consistently with the attached test case, which runs
>>>>> gdb in a subprocess. One has to kill the gdb process before the main
>>>>> program exits.
>>>>>
>>>>> The STC runs as expected on Linux.
>>>>
>>>> Thanks for the STC. I had to tweak it to actually see how it was supposed
>>>> to work on Linux since only a limited number of lines from the pty were
>>>> being output. I've included the revised test case below.
>>>>
>>>> I made a simple change to Cygwin which will probably cause subtle
>>>> problems somewhere down the line. At least for now it seems to make gdb
>>>> operate as expected.
>>>>
>>>> I'm building a new snapshot now.
>>>
>>> Thanks, that fixes it (as well as the emacs problem that originally led
>>> to this report). In case there are emacs users wondering what this is
>>> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
>>> obsolete gdb --annotate=3 used by emacs-23.
>>
>> I'm replying to this old thread because the problem is back again in
>> cygwin-1.7.14-2.  I haven't checked to see exactly when it first
>> reappeared (but I'll do this if it would help.)  The same STC as before
>> exhibits the problem; I'm attaching it for convenience.
>
> Thanks for the heads up.  This should be fixed in the next snapshot.

Confirmed.  Thanks.

Ryan, if you're reading this, the problems you were seeing with M-x gdb 
in emacs should be fixed now.

> Incidentally, I've started putting longer explications of what I've
> debugged and how I debugged it in a "DevNotes" file in the source:
>
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes?cvsroot=src
>
> I hope to keep this up-to-date with extended rationales for why things
> were done a certain way and with descriptions about the steps that I
> used to track down a problem.
>
> This file is not a substitute for comments (we've been trying to be more
> diligent about commenting changes in the source) or a ChangeLog but I
> hope that it will help me in the future when I have to figure out "Why
> the heck did I make that change?"

Great idea.  It's also useful for people like me who like to understand 
what caused a problem they reported and how it got fixed.

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