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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=XChPNwQxVO0rWaxILM1t+G2712NjI0er0/r4sTpRYKh
	5NzrJxmhgzGM6ip9c2i4ZaUUN68rXPcK1gaAFXFmCB65+lHq5/vZX7JsKrGLmdwk
	ShiqgBbJLGAXgsBiFeupE0PgoAIv47cSaTvkyM0jtdIdk5wkAE36o9oxrI69MXWM
	=
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=yVaJX0znUVdLi1LOogRKKqhEhjg=; b=HI7jiBrH2uzmSl1BE
	7hgsDhXcTc7wjld1HwDwNv3B0sDcVdYaAt0GMGgjLOt/Qzlu0L7BGDtFrQnpyqHW
	QUN6vOH59e868qr0+rQOe3/hrw96dEyemEXLOYVCTKjWiS2KUcXNh4cLU5zC6a/m
	lB+m2vwIeAyQXqeqH/x4xDVTiw=
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
X-Spam-SWARE-Status:	No, score=-0.4 required=5.0 tests=AWL,BAYES_50,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_NEUTRAL autolearn=no version=3.3.1
Message-ID:	<51F6C22D.70708@cs.utoronto.ca>
Date:	Mon, 29 Jul 2013 15:27:41 -0400
From:	Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT 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 AT cygwin DOT com
Subject:	Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
References:	<51F33E9D DOT 9030703 AT cs DOT utoronto DOT ca> <51F3A133 DOT 8090805 AT star DOT sr DOT bham DOT ac DOT uk> <20130729110626 DOT GB30069 AT calimero DOT vinschen DOT de> <51F691D2 DOT 205 AT cs DOT utoronto DOT ca> <20130729191118 DOT GG4166 AT calimero DOT vinschen DOT de> <51F6BEF0 DOT 10003 AT cs DOT utoronto DOT ca>
In-Reply-To:	<51F6BEF0.10003@cs.utoronto.ca>

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

> 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

- Raw text -