X-Recipient: archive-cygwin@delorie.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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=fkjM5D8h8iTMTkxUXbYD95kGtGoB/WcIBz3pP+ZXmJa
	9fczKBSSc3y8P6Ax7BB06jlRs+y6XvEjQM7Ogqk52lMDyvNYMJZbYh4wSf67pzw0
	Ubm39qC13uRKGzGAy5Ul6Hw7k47GpJrSC8AWHFbbrRF+caOL112z3E5Ue2i6/M+8
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=E1Aj6aXUUxoiV+uiRqy24KeVedw=; b=ekDvpwiYp+TEi0Pre
	jLIbWk7U2TcXl3XC2rIHVtRu0+TzHqtnQDYjn4rpwKV0VmYFzcbo18dL6Aq3wxQe
	JWl5r1b1W1VhCZsTNX2zJ+tEeUyVvby+M6kT+EI2jO3C0Lx06Xwxiz//1qAFX0vH
	0mgMm/bJWaGVtBipudmcm0XmMc=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_NEUTRAL autolearn=no version=3.3.1
Message-ID: <51F91C84.3020809@cs.utoronto.ca>
Date: Wed, 31 Jul 2013 10:17:40 -0400
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
References: <51F33E9D.9030703@cs.utoronto.ca> <51F3A133.8090805@star.sr.bham.ac.uk> <20130729110626.GB30069@calimero.vinschen.de> <51F691D2.205@cs.utoronto.ca> <20130729191118.GG4166@calimero.vinschen.de> <51F6BEF0.10003@cs.utoronto.ca> <51F6C22D.70708@cs.utoronto.ca>
In-Reply-To: <51F6C22D.70708@cs.utoronto.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29/07/2013 3:27 PM, Ryan Johnson wrote:
> On 29/07/2013 3:13 PM, Ryan Johnson wrote:
>> On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
>>> On Jul 29 12:01, Ryan Johnson wrote:
>>>> On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
>>>>> On Jul 27 11:30, Daniel Brown wrote:
>>>>>> I have also ran into this problem, in my case though I have managed
>>>>>> to reduce the issue down to an fgets call when reading a pipe.
>>>>>> The following code causes the issue for me if I try and debug it:
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <stdlib.h>
>>>>>>
>>>>>> int main(int argc, char** argv) {
>>>>>>      char out[100] = {0};
>>>>>>      FILE *pipe;
>>>>>>
>>>>>>      if ((pipe = popen("uname -r", "rt")) == NULL)
>>>>>>          fprintf(stderr,"Failed to execute popen command");
>>>>>>
>>>>>>      if(fgets(out, 100, pipe) == NULL)
>>>>>>          fprintf(stderr,"Failed to read popen buffer");
>>>>>>
>>>>>>      printf("%s\n", out);
>>>>>>
>>>>>>      pclose(pipe);
>>>>>>
>>>>>>      return (EXIT_SUCCESS);
>>>>>> }
>>>>>>
>>>>>> I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
>>>>>> error `invalid decimal " 0x23DBF0"` then pops up.
>>>>>> I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
>>>>>> and the error is still there.
>>>>> This is a problem in GDB, not in the Cygwin DLL.  My mistake.  I 
>>>>> fetched
>>>>> the official 7.6 version of GDB since it already contained Cygwin 
>>>>> x86_64
>>>>> support so I thought it's sufficient.  Unfortunately it doesn't 
>>>>> handle
>>>>> special Cygwin strings in terms of Cygwin signal handling correctly.
>>>>>
>>>>> I'm just uploading a gdb-7.6.50 version build from current CVS which
>>>>> should fix this.
>>>> Confirmed that this problem is fixed [1]... however, my original STC
>>>> still hangs because gdb somehow interferes with the choreography of
>>>> SIGTSTP between victim and its owning shell.
>>>>
>>>> With default signal handling (SIGTSTP stop print pass) gdb breaks in
>>>> when the victim receives ^Z, but both gdb and the victim hang once
>>>> gdb continues; gdb cannot be interrupted with ^C [2]. Killing gdb
>>>> allows the victim to finish backgrounding itself, apparently none
>>>> the worse for wear.
>>> I'm not sure if ^Z can reliably work in the GDB scenario. That's
>>> Chris' domain, but AFAICS, the fact that GDB calls the inferior
>>> process with CreateProcess, the job control facility of the shell
>>> will be broken.
>> I'm talking about the case where gdb attaches to a running 
>> proccess... I don't know how you could ever handle ^Z in a process 
>> gdb started.
> Just to be extra clear, the scenario is:
> 1. start STC in terminal A
> 2. start gdb in terminal B and attach it to the STC
> 3. type ^Z in terminal A
Is there something I can do to help move this along? It's making it hard 
to debug the sporadic emacs crashes I've been getting (turns out the 
same thing happens for SIGINT, so avoiding the temptation to hit ^Z 
isn't enough).

Thanks
>> Ryan
>
>
> -- 
> 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
>


--
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

