From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13689 invoked by alias); 31 Oct 2005 14:18:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 13657 invoked by uid 22791); 31 Oct 2005 14:18:06 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 31 Oct 2005 14:18:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EWaU5-0006ei-H3; Mon, 31 Oct 2005 09:18:01 -0500 Date: Mon, 31 Oct 2005 14:18:00 -0000 From: Daniel Jacobowitz To: Andrew Walrond Cc: gdb@sources.redhat.com Subject: Re: gdb drops out with 'I/O possible message' Message-ID: <20051031141800.GA25504@nevyn.them.org> Mail-Followup-To: Andrew Walrond , gdb@sources.redhat.com References: <200510282330.00638.andrew@walrond.org> <200510310653.49726.andrew@walrond.org> <200510311003.10718.andrew@walrond.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510311003.10718.andrew@walrond.org> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00231.txt.bz2 On Mon, Oct 31, 2005 at 10:03:10AM +0000, Andrew Walrond wrote: > On Monday 31 October 2005 09:43, Andreas Schwab wrote: > > > > Some process (ruby?) is probably enabling async I/O on stdin, which causes > > all processes in the same process group to receive SIGIO whenever > > something is available to be read on stdin. Then the process crashes and > > has no chance to disable async I/O. With the next debugging session a new > > process group is created, but the SIGIO signals are still sent to the old > > (now defunct) process group, effectively dropping them on the floor. > > So is gdb in the same process group as the debug target process? (FWIW the > process in question forks off several other processes) And will receive the > same SIGIOs? It should not be; it goes to some effort to always keep the foreground process group set correctly. > In other (non ruby) applications where I have seen this problem, I do > > std::ios::sync_with_stdio(false) > > which presumably enables async I/O on stdin/stdout etc. No, that has nothing to do with async I/O; it's just a question of buffering. -- Daniel Jacobowitz CodeSourcery, LLC